UPPSALA UNIVERSITET F¨oretagsekonomiska institutionen Kandidatuppsats, C-niv˚a
HT 2009
Kronofogdens upphandling av aff¨arssystem
Best¨ allarkompetens inom offentlig upphandling
Sammanfattning
I denna uppsats unders¨oks hur Kronofogden har byggt upp sin best¨allarkompetens inf¨or och under upphandlingen av sitt f¨orsta aff¨arssystem, samt vilken inverkan behovet av best¨allarkompetens har haft p˚a upphandlingens uppl¨agg.
Genom att studera den upphandlingsprocess Kronofogden bedrev vid upphandling av nytt aff¨arssystem och med hj¨alp av en modell f¨or best¨allarkompetens identifieras vilka faktorer som p˚averkat upphandling- en samt vilken inverkan dessa faktorer haft.
Kronofogden har byggt upp sin best¨allarkompetens genom att utg˚a ifr˚an verksamhetens behov och l¨art sig hur ett aff¨arssystem kan tillfreds- st¨alla behovet. D¨arigenom har man f¨orb¨attrat sina m¨ojligheter att ge- nomf¨ora en framg˚angsrik upphandling trots att Kronofogden inte har n˚agra tidigare erfarenheter av aff¨arssystem. Utifr˚an den f¨orst˚aelse Kro- nofogden har byggt upp r¨orande aff¨arssystem har man valt att begr¨ansa sin l¨osning f¨or att sedan forts¨atta successivt och genom att anv¨anda ett testsystem har de f˚att in en extra s¨akerhet i upphandlingen.
F¨orfattare: Handledare:
Inneh˚ all
1 Inledning 3
1.1 Upphandling av aff¨arssystem . . . 4 1.2 Kronofogdens upphandling . . . 5
2 Syfte 6
2.1 Avgr¨ansningar . . . 6
3 Teori 7
3.1 Informationssystem . . . 7 3.2 Organisatoriska ink¨op . . . 11 3.3 Teoretiskt ramverk . . . 15
4 Metod 18
4.1 Hur den teoretiska referensramen anv¨ands . . . 18 4.2 Hur unders¨okningen har genomf¨orts . . . 18 4.3 Unders¨okningens trov¨ardighet . . . 20
5 Empiri 21
5.1 Kronofogdemyndigheten . . . 21 5.2 Upphandlingsprojektet . . . 24 5.3 Leverant¨orernas reflektioner p˚a upphandlingen . . . 28
6 Analys 30
6.1 Kronofogden & aff¨arssystem . . . 30 6.2 Upphandlingen . . . 31
7 Diskussion och slutsatser 34
7.1 Kronofogdens upphandling . . . 34 7.2 Uppsatsens resultat . . . 35
Referenser 37
Bilaga A - Intervjufr˚agor 40
1 Inledning
Det s¨ags att h¨alften av alla IT-projekt havererar, de drar ¨over budgeten, drar ut p˚a tiden och levererar s¨allan det som lovats. Ett vanligt p˚ast˚aende om IT idag
¨ar att det kostar f¨or mycket, det ger inte valuta f¨or pengarna och f¨oretag vill oftast minska kostnaderna f¨or IT. ¨And˚a best˚ar IT-relaterade investeringar f¨or en stor del av de investeringar som genomf¨ors av ett f¨oretag, och kostnaderna f¨or att driva ett IT-system ¨okar. Samtidigt verkar det vara oklart vad f¨oretaget egentligen f˚ar f¨or pengarna. En anledning till detta ¨ar att IT har blivit n˚agot av ett universalverktyg som ska l¨osa alla problem. Flera exempel visar att ett av de stora problemen med IT ¨ar att verksamheter ¨ar d˚aliga p˚a att upphandla IT-tj¨anster. Det handlar d˚a om vilka tj¨anster som beh¨ovs samt vilka krav man ska st¨alla p˚a dessa tj¨anster. Detta ¨ar en av huvudorsakerna till skenande IT- kostnader. Best¨allaren vet inte vad man vill f˚a ut fr˚an informationssystemet och d¨arf¨or ser man inte heller alltid vad man f˚ar, och vad man d¨armed betalar f¨or.
(Kurt´en, 2009, sid. 133ff)
S˚a lite som en tredjedel av alla stora IT-projekt levereras i tid, inom budget och med utsatt funktionalitet. S˚a h¨ar har det sett ut de senaste 40 ˚aren, ¨aven om vissa sektorer inom n¨aringslivet ¨ar b¨attre ¨an andra finns det ¨aven de som fortfarande ligger efter och det g¨aller i dagsl¨aget framf¨orallt offentlig sektor. D¨ar har det inte blivit n˚agon riktig f¨orb¨attring utan varje g˚ang en s˚adan offentlig verksamhet ska byta IT-system blir det problem. Det ¨ar inte hos det k¨opta systemet som problemen finns utan felet ligger p˚a best¨allarsidan och de som misslyckas g¨or alla samma misstag. Genom att anv¨anda en specifikation som ¨ar f¨or omfattande och samtidigt saknar de viktigaste kraven. Projekten ska spegla verksamheten och i specifikationen m˚aste verksamhetskraven finnas med f¨or att ett projekt ska lyckas. (Computer Sweden, 2009c)
Ett av de mest omskrivna aff¨arssystemen idag ¨ar ett av F¨ors¨akringskassans p˚ag˚aende projekt. Det som har uppm¨arksammats ¨ar de ¨okande kostnaderna f¨or projektet, under ˚ar 2008 ¨overskreds budgeten med 175 miljoner kronor.
(Computer Sweden, 2009a) Delleveranser av systemet har inte fungerat som planerat och har p˚a s˚a s¨att p˚averkat verksamhet och slutkunder negativt n¨ar utbetalningar inte skett i tid. Bakgrunden till sv˚arigheterna anses vara det bristf¨alliga underlag som framst¨alldes inf¨or upphandlingen. (Computer Swe- den, 2009b)
1.1 Upphandling av aff¨ arssystem
Ett aff¨arssystem ¨ar ett verksamhets¨overgripande system som hanterar ett f¨oretags behov av styrning och administration. M˚alet ¨ar ett system som hanterar all information inom f¨oretaget som en enda stor databas. Olika applikationer i aff¨arssystemet arbetar med samma data, information om en anst¨alld, en kund eller en produkt. ¨Andringar beh¨over bara g¨oras p˚a ett st¨alle f¨or att ¨andringen ska sl˚a igenom ¨overallt, den nya informationen blir tillg¨anglig f¨or alla samti- digt. Aff¨arssystem omfattar funktioner f¨or s˚adant som redovisning, order, lager, fakturering, personaladministration, kundhantering och produktionsplanering (Computer Sweden, 2009d)
Leverant¨orerna SAP och Oracle har under senare ˚ar m¨arkt en f¨or¨andring p˚a marknaden f¨or aff¨arssystem, det har blivit mer attraktivt f¨or offentliga verk- samheter att k¨opa in l¨osningar. (Eriksson, 2009; Lindberg, 2009) Den typiska kundgruppen p˚a aff¨arssystemsmarknaden har brett ut sig fr˚an vanliga f¨oretag till bank- och f¨ors¨akringsverksamhet vidare mot offentlig sektor. Verksamheter i den offentliga sektorn har uppm¨arksammat att deras processer inte skiljer sig fr˚an andra privata verksamheter p˚a n˚agot kritiskt s¨att. (Lindberg, 2009)
F¨or att g¨ora en lyckad investering i aff¨arssystem m˚aste verksamheten se p˚a problemet utifr˚an ett vidare och mer l˚angsiktigt perspektiv. D˚a offentlig sektor m˚aste f¨olja lagen om offentlig upphandling ¨ar det framf¨orallt viktigt att ha en tydlig ¨overgripande strategi eftersom en verksamhet annars riskerar att f˚a in sn¨avt specialiserade produkter f¨or varje funktion vilket i slut¨andan resulterar i en stor m¨angd sm˚a system som ¨ar dyra och kr¨avande att integrera med varand- ra. (Lindberg, 2009) Det ¨ar d¨arf¨or viktigt att upphandlingsfasen g˚ar r¨att till och tar den tid som beh¨ovs f¨or att s¨akerst¨alla utg˚angen av investeringen. F¨or en lyckad upphandling m˚aste ett anbudsunderlag skapas som beskriver vad verk- samheten ¨ar, hur den fungerar och hur de dagliga processerna ser ut. Vidare ska underlaget ¨aven tillhandah˚alla en kravspecifikation som redog¨or f¨or verk- samhetens f¨orv¨antningar p˚a det nya systemet, hur systemet ska st¨odja rutiner f¨or informationsbearbetning etc. Kravst¨allningen ¨ar en viktig del i arbetet med byte av aff¨arssystem d˚a den ˚aterkommer under flera moment. Den anv¨ands f¨or att beskriva behovet f¨or leverant¨orer, som underlag vid val av aff¨arssystem och slutligen som underlag f¨or testningen av systemet. (Andersson, 2008, sid. 14ff)
1.2 Kronofogdens upphandling
Kronofogdens verksamhet handlar i huvudsak om att fastst¨alla och driva in statliga och privata skulder. (W¨asterlid, 2009) Denna f¨ordelning av pengar sk¨ots i dagsl¨aget av det egenutvecklade systemet REX som togs i drift 1975. Sedan dess har Kronofogden sj¨alva gjort tre f¨ors¨ok att byta ut REX mot ett modernare system, dessa f¨ors¨ok har av olika anledningar misslyckats. (Persson, 2009)
N¨ar Kronofogden f¨or fj¨arde g˚angen best¨amde sig f¨or att byta system anv¨ande de konsultf¨oretaget Capgemini f¨or att unders¨oka vilka m¨ojligheter som fanns. Med Capgeminis unders¨okning som grund beslutade Kronofog- den att ett aff¨arssystem var en potentiell l¨osning. Kronofogden tittade p˚a F¨ors¨akringskassans byte av aff¨arssystem och den problematik som funnits d¨ar.
Kronofogden ins˚ag att ingen inom deras organisation visste hur standardsystem fungerar, men man ville inte helt ¨overl˚ata projektet till konsulter p˚a grund av risken att f˚a ett system som inte uppfyller verksamhetens behov. F¨or att und- vika konsultberoendet beslutade man att f¨orst upphandla ett testsystem f¨or utv¨ardering och i samband med detta l¨ara personalen hur ett standardsystem fungerar, samtidigt som Kronofogden kunde bilda sig en uppfattning om vad som kr¨avs f¨or att systemet ska kunna anpassas till verksamheten. (Persson, 2009)
2 Syfte
Syftet med denna uppsats ¨ar att unders¨oka hur Kronofogden i egenskap av att vara en offentlig verksamhet kan tillgodog¨ora sig den kunskap som kr¨avs f¨or att upphandla ett aff¨arssystem med en efters¨okt funktionalitet. Detta kommer att g¨oras genom att studera den upphandlingsprocess Kronofogden bedrev vid upphandling av nytt system, d¨ar man valt att f¨orst utv¨ardera ett testsystem.
Uppsatsen kommer bland annat att belysa vad detta testsystem kan bidra med och varf¨or det ¨ar l¨ampligt att anv¨anda ett s˚adant.
• Hur har Kronofogden byggt upp sin best¨allarkompetens inf¨or och under upphandlingen av sitt aff¨arssystem?
• Vilken inverkan har best¨allarkompetensen haft p˚a upphandlingens ge- nomf¨orande?
• Vad har testsystemet bidragit med i denna upphandling?
2.1 Avgr¨ ansningar
Under den upphandlingsprocess vi studerar har ett flertal akt¨orer varit inblan- dade s˚asom samarbetspartners, referenser och leverant¨orer, men vi har valt att fokusera p˚a Kronofogdens roll och endast vid behov redog¨ora f¨or andra akt¨orers inblandning. Vi g¨or denna avgr¨ansning eftersom det ¨ar akt¨orernas roll under processen som ¨ar intressant utifr˚an uppsatsens syfte och inte akt¨orerna i sig.
3 Teori
Detta avsnitt syftar till att ge en teoretisk referensram som behandlar den kompe- tens en verksamhet beh¨over besitta vid upphandling av ett aff¨arssystem. Utifr˚an denna referensram kommer vi sedan att unders¨oka hur Kronofogden har byggt upp sin best¨allarkompetens. Teoriavsnittet inleds med en redog¨orelse f¨or teorier om relevanta systembegrepp och upphandling av aff¨arssystem f¨or att sedan av- slutas med en motivering till varf¨or vi valt denna teori och den modell vi byggt utifr˚an den.
3.1 Informationssystem
Det ¨ar viktigt att skilja p˚a data och information. N¨ar uppgifter ¨ar lagrade i ett system betraktas de som data men n¨ar en m¨anniska anv¨ander uppgifterna till n˚agot meningsfullt f¨orvandlas data till information. Ren data skapar inte n˚agot v¨arde f¨or verksamheten, v¨ardet skapas f¨orst n¨ar data blir till information. Detta gl¨oms l¨att bort i IT-projekt och de ses som rent tekniska projekt d¨ar man inte tar h¨ansyn till de m¨anskliga och sociala aspekterna. Ny teknik ¨ar endast v¨ardefull om den st¨odjer eller f¨orb¨attrar arbetsprocesser i verksamheten. (Kurt´en, 2009, sid. 42ff) Ett informationssystem b¨or ses som ett sociotekniskt system d˚a det inneh˚aller b˚ade informationsteknologi och m¨anskliga aktiviteter. Det involve- rar m¨anniskor vid produktion, insamling och bearbetning av information. Ett informationssystem ¨ar skilt fr˚an informationsteknologi men det inneh˚aller infor- mationsteknologi f¨or att underl¨atta arbetet i systemet. (Beynon-Davies, 2002, sid. 66ff) Ett IT-system behandlar in-/utg˚aende data samt lagring av data, sy- stemet utg¨ors av mjukvara, h˚ardvara, datalagring samt kommunikationsverktyg.
Informationssystem d¨aremot handlar om informationsutbyte mellan olika par- ter, kommunikation mellan m¨anniskor, och har d¨armed funnits sedan l˚angt f¨ore dagens informationsteknologi. D¨aremot best˚ar moderna informationssystem i dagens komplexa organisationer ¨aven av IT-system som en delkomponent f¨or att st¨odja arbetet i informationssystemet. Det ¨ar vanligt att begreppet informa- tionssystem syftar p˚a ett informationssystem d¨ar informationsteknologin r¨aknas som en delkomponent. (Beynon-Davies, 2002, sid. 159ff)
All information b¨or ¨agas av verksamhetssidan d˚a det ¨ar den som ansvarar f¨or en process som vet hur viktig dess information ¨ar f¨or verksamheten. En intern eller extern IT-avdelning ska tillhandah˚alla de informationstj¨anster som process¨agaren best¨aller. IT-avdelningen ska ¨aven f¨olja den tekniska utvecklingen
och ge r˚ad om ny teknik som finns, men de f˚ar inte sj¨alvst¨andigt fatta beslut om vad verksamheten beh¨over. (Kurt´en, 2009, sid. 59)
Tanken ¨ar att informationen styr informationssystemet som i sin tur driver informationsteknologins utveckling. En organisation m˚aste f¨orst identifiera be- hovet av information f¨or att sedan kunna best¨amma hur ett informationssystem ska tillfredsst¨alla detta behov. Slutligen m˚aste best¨ammas vilken informations- teknologi som b¨ast kan st¨odja informationssystemet. (Beynon-Davies, 2002, sid.
434)
Ett f¨oretags aff¨arsarkitektur beskriver verksamhetens hierarkiska organisa- tion och innefattar en processkarta ¨over k¨arnprocesser och st¨odprocesser. Den omfattar ¨aven dokumentation f¨or informationsarkitektur, policydokument som bland annat beskriver f¨oretagets strategiska m˚als¨attning samt andra riktlinjer f¨or att st¨odja beslutsfattande p˚a olika niv˚aer i verksamheten. I aff¨arsarkitekturen ska ¨aven arkitekturen f¨or verksamhetens integrerade informationssystem finnas.
(Kurt´en, 2009, sid. 74)
Modern processorienterad verksamhet grundar sig i att information fl¨odar horisontellt och allts˚a inte genom olika avdelningars chefshierarkier. Det ¨ar pro- blematiskt att skapa en arkitektur som uppfyller detta horisontella informa- tionsfl¨ode, fr¨amst n¨ar m˚anga system ¨ar inblandade och speciellt ¨aldre system som inte ¨ar byggda f¨or denna typ av kommunikation. F¨or att kunna l¨osa de pro- blem som uppst˚ar har informationssystem b¨orjat tillverkas utifr˚an standarder som ska g¨ora kommunikationen mellan olika system l¨attare, l¨osningen inneb¨ar att ett system byggs i moduler. Dessa moduler fungerar som ett skal f¨or sy- stemet d¨ar den tillhandah˚aller specifika informationstj¨anster p˚a insidan men kan f¨ormedla information till externa anropare p˚a ett standardiserat s¨att. Detta kallas f¨or en tj¨ansteorienterad arkitektur (eng. Service Oriented Architecture, SOA). SOA ¨ar anv¨andbart n¨ar ¨aldre informationssystem ska integreras med ny- are system. Det ¨ar ¨aven anv¨andbart n¨ar informationssystem ur helt olika milj¨oer eller infrastrukturer ska knytas ihop. (Kurt´en, 2009, sid. 75ff)
3.1.1 Aff¨arssystem
Aff¨arssystem ( eng. enterprise resource planning, ERP) best˚ar av ett antal olika verksamhetsfunktioner som ¨ar integrerade under samma system och baseras p˚a id´en om ett s¨oml¨ost fl¨ode av information mellan administration, f¨ors¨aljning och produktion. (Beynon-Davies, 2002, sid. 159) Detta kallas vardagligt f¨or ett stan- dardsystem och inneb¨ar en f¨ardigpaketerad produkt, ett f¨ardigprogrammerat
IT-system. De ¨ar oftast skapade f¨or olika branscher eller verksamhetsfunktioner s˚asom kundtj¨anst eller redovisning. Funktionerna ¨ar dock byggda efter generella rutiner vilket inneb¨ar att de inte n¨odv¨andigtvis helt motsvarar den ink¨opande verksamhetens funktioner. Det g˚ar att k¨opa f¨ardiga paket som kan anpassas och skr¨addarsys f¨or verksamheten genom att programmera och konfigurera pa- rametrar hos systemet. Det ¨ar ¨aven vanligt att dessa system ¨ar uppbyggda av moduler vilket medf¨or att verksamheten k¨oper in och implementerar funktio- nalitet i form av olika funktionsmoduler som systemet tillhandah˚aller. (Bocij, Chaffey, Greasley and Hickie, 2006, sid. 312)
En verksamhet beh¨over inte anv¨anda en aff¨arssystemsstrategi, d¨ar ett aff¨arssystem s¨oks som helhetsl¨osning, utan kan med en s˚a kallad “Best-of- Breed”-strategi (BoB) bygga upp ett informationssystem av flera system f¨or att f˚a en l¨osning som b¨attre st¨odjer verksamheten. Med en BoB-strategi v¨aljer organisationen det aff¨arssystem som ¨ar b¨ast l¨ampat f¨or en efters¨okt funktiona- litet. (Light, Holland and Wills, 2001)
Det kan vara s˚a att systemet inte passar alla verksamhetsfunktioner och d˚a kan en s˚akallad hybridl¨osning vara n¨odv¨andig. Detta inneb¨ar att ett stan- dardsystem kompletteras och modifieras med egenutvecklade till¨agg f¨or att f˚a den efters¨okta helheten. Egenutveckling till skillnad fr˚an standardiserade l¨osningar ger h¨ogre fokus p˚a verksamhetsspecifik funktionalitet d˚a utvecklingen blir skr¨addarsydd efter de krav som ¨ar st¨allda p˚a systemet. Nackdelar med ett egenutvecklat system ¨ar de os¨akra kostnaderna, sv˚arigheten att h˚alla tidspla- neringen samt att kvalit´en kan brista i form av att systemet inneh˚aller m˚anga buggar. (Bocij et al., 2006, sid. 312ff)
Att aff¨arssystem ¨ar kompletta l¨osningar medf¨or inte att alla gamla system inte beh¨ovs l¨angre utan det vanligaste ¨ar att vissa system som utg¨or specifi- ka verksamhetsfunktioner m˚aste integreras. Det ¨ar en del av implementatio- nen som tar upp en st¨orre del av tiden av implementationen. (Markus, Axline, Petrie and Tanis, 2000) Att integrera ett aff¨arssystem mot andra program och system ¨ar n˚agot som har visat sig ta upp h¨alften av budgeten vid inf¨orandet.
Det medf¨or oftast till¨agg och modifieringar som sedan blir problematiska och kr¨avande att bibeh˚alla under systemuppdateringar. (Al-Mashari, Al-Mudimigh and Zairi, 2003)
3.1.2 Implementation
Att implementera ett nytt aff¨arssystem i en verksamhet handlar om sociotek- nisk design. M˚alet ¨ar att f˚a IT-systemet och m¨anskliga aktiviteter att fungera tillsammans f¨or att f¨orb¨attra verksamhetens processer och rutiner. IT-systemet byggs oftast upp utifr˚an verksamheten men kan ¨aven inneb¨ara f¨or¨andringar i rutiner, verksamheten kan bli tvungen att anpassa sig efter systemet. (Beynon- Davies, 2002, sid. 354ff) Vid implementation ¨ar det viktigt att det befintliga systemet blir noggrant utv¨arderat s˚a att problem som kan uppst˚a under imple- mentationen kartl¨aggs. Problemen med en verksamhets befintliga system beror oftast p˚a att de ¨ar komplexa med data utspridd ¨over ett flertal system. Kom- plexiteten medf¨or att niv˚an p˚a de tekniska och organisatoriska f¨or¨andringarna blir h¨oga. Det ¨ar d¨arf¨or viktigt att ¨overg˚angen till ett aff¨arssystem sker utifr˚an en omsorgsfull planering. (Al-Mashari et al., 2003)
F¨or effektivare utveckling under implementationen ¨ar det vanligt att anv¨anda sig utav prototyping, en metod d¨ar m˚alet ¨ar att ¨oka utvecklingshastigheten ge- nom att involvera anv¨andarna. Prototyping g˚ar ut p˚a att en testversion av systemet skapas f¨or att l˚ata anv¨andarna utv¨ardera den och sedan ge feedback.
Detta sker i en iterativ process d¨ar tester utf¨ors och utv¨arderas vilket stegvis f¨orb¨attrar systemet. (Bocij et al., 2006, sid. 336ff) N¨asta steg ¨ar att implemente- ra informationssystemet i verksamheten, b˚ade tekniskt och socialt. Det tekniska inneb¨ar att h˚ardvara, mjukvara och kommunikationen mellan dem ska komma p˚a plats medan det sociala inneb¨ar att personalen ska involveras, allts˚a l¨ara sig att anv¨anda det nya systemet. (Beynon-Davies, 2002, sid. 372)
Implementering av aff¨arssystem ¨ar i m˚anga avseenden en socialt komplex si- tuation p˚a grund av att det ¨ar m˚anga intressen och f¨oretag inblandade. Projek- tet best˚ar i regel av verksamhetspersonal, b˚ade vanlig och IT-personal, personal fr˚an leverant¨oren samt fr˚an en eller flera konsultfirmor. Att organisera och ko- ordinera projektet ¨ar en utmaning p˚a grund av de olika kompetensomr˚aden som m˚aste involveras. Sv˚arigheter har uppt¨ackts med att uppr¨atth˚alla kompetens- niv˚an under hela projektet d˚a konsulter ¨ar specialister som ofta byts ut efter att deras omr˚ade ¨ar avverkat. (Markus et al., 2000) Projektledningen m˚aste finnas f¨or att hantera konflikter och s¨akerst¨alla att kommunikationen fungerar mel- lan de olika intressenternas omr˚aden f¨or att inf¨orandet av ett aff¨arssystem ska lyckas. (Chen, Law and Yang, 2009) Det ¨ar viktigt att ha en stark projektled- ning som kan s¨atta sig in systemet och verksamheten och fatta beslut d¨arefter.
(Al-Mashari et al., 2003)
3.2 Organisatoriska ink¨ op
Ink¨opsprocessen i samband med ink¨op brukar i stora drag beskrivas uti- fr˚an att n¨ar behov uppst˚ar s˚a identifieras alternativa l¨osningar samt leve- rant¨orer f¨or att sedan utv¨arderas och slutligen utsees en leverant¨or som vinnare.
(Axelsson, 1998, sid. 66) De best˚andsdelar som karakteriserar ink¨opsbeteendet
¨ar alternativen som ¨overv¨ags, resurssatsningen och vilka fr˚agor som domine- rar i dialogen med leverant¨oren samt internt inom ink¨opsgruppen. Beroende p˚a vad som ska k¨opas v¨ager dessa fr˚agor olika, standardiserade produkter st¨aller exempelvis inte samma krav som specialiserade produkter. Vid ink¨op av spe- cialiserade produkter ¨ar det vanligt att ink¨opet f¨oreg˚as av en upphandling f¨or att best¨allaren ska kunna utv¨ardera leverant¨orers olika l¨osningar och erbju- danden. Informationsutbytet mellan parterna ¨okar beroende p˚a hur komplex l¨osningen ¨ar. (Axelsson, 1998, sid. 97ff) N¨ar komplexiteten ¨okar blir det vik- tigt att g¨ora ink¨op som utg˚ar ifr˚an relations- och samarbetsinriktade l¨osningar, d¨ar best¨allaren ¨ar ute efter en mer l˚angsiktig relation till leverant¨oren som bygger p˚a att problem l¨oses inom relationen och inte genom leverant¨orsbyte.
(Axelsson, 1998, sid. 254)
Organisering av ink¨op, funktionens bemanning och arbetss¨att, ¨ar situations- betingat. Det som ¨ar r¨att f¨or ett f¨oretag i en viss situation kan vara fel f¨or ett annat. Olika ink¨opssituationer st¨aller skilda krav p˚a ink¨opsfunktionen och k¨op av tj¨anster av olika slag kr¨aver anpassad ink¨opskompetens f¨or tj¨ansten ifr˚aga.
Inom ink¨op finns f¨oruts¨attningar f¨or att skapa m¨ojligheter men detta kan ocks˚a resa hinder f¨or f¨oretaget, m¨ojligheterna begr¨ansas av ink¨opsfunktionens beman- ning och kompetens samt av hur arbetet ¨ar organiserat med andra ber¨orda enheter inom f¨oretaget. Det ¨ar ink¨opets f¨oruts¨attningar som ska l¨agga grun- den f¨or arbetss¨attet och som i sin tur ger resultatet. Med f¨oruts¨attningar f¨or ink¨op menas samspelet mellan krav, behov och m¨ojligheter samt resur- ser och organiserad f¨orm˚aga. Arbetss¨attet ska kretsa kring viktiga aspek- ter i dialoger externt och internt samt kring samordning och samspel inom ink¨opsfunktionen.(Axelsson, 1998, sid. 381ff)
F¨oretag k¨oper oftast tj¨anster d¨arf¨or att de inte har f¨orm˚agan att sj¨alva fylla funktionen p˚a ett effektivt s¨att eller inte vill l¨agga ner egna resurser p˚a det. F¨oretaget vill ist¨allet komplettera den egna organisationen genom att k¨opa en funktion av h¨og kvalitet. (Axelsson, 1998, sid. 51) Precisering av tj¨anstens funktioner och kvalit´eer samt vilka interna avdelningar som kommer att ber¨oras under ink¨opsprocessen och bed¨omningarna av olika leverant¨orers f¨orm˚aga ¨ar
olika aspekter som h¨ar m˚aste hanteras p˚a ett anpassat s¨att. Faktorer som kan spela in ¨ar om leverant¨oren ¨ar k¨and hos best¨allaren eller inte, bed¨omningen blir annorlunda om det ¨ar f¨orsta aff¨aren mellan parterna. Det ¨ar ¨aven sv˚art att precisera inneb¨orden av en tj¨anst b˚ade f¨or kund och leverant¨or. ¨Aven om det klarg¨ors vems ansvar vissa aktiviteter eller funktioner ¨ar s¨ager det v¨aldigt lite om kvaliteten i utf¨orandet av dessa. F¨or att kunna precisera vad tj¨ansten f¨orv¨antas best˚a av m˚aste klarg¨oras vilka resurser som ska satsas, hur genomf¨orandet ska g˚a till samt vad det f¨orv¨antade resultatet ¨ar. (Axelsson, 1998, sid. 66ff)
3.2.1 Lagen om offentlig upphandling
Lagen om offentlig upphandling (LOU) reglerar ink¨opsf¨orfarandet f¨or varor och tj¨anster inom offentlig sektor. Ink¨op ska ske genom anbudsf¨orfaranden p˚a en marknad d¨ar f¨oretag konkurrerar om att bli leverant¨orer till den offentliga sek- torns olika verksamheter. Den upphandlande verksamheten ska utnyttja svensk och utl¨andsk konkurrens samt upptr¨ada objektivt och aff¨arsm¨assigt. Vid en offentlig upphandling finns det ett tr¨oskelv¨arde f¨or det belopp ink¨opet hand- lar om, detta avg¨or om upphandlingen skall annonseras f¨or hela EU (¨over tr¨oskelv¨ardet) eller enbart f¨or Sverige (under tr¨oskelv¨ardet). Vid upphandling
¨over tr¨oskelv¨ardet kan den upphandlande verksamheten v¨alja mellan tre oli- ka alternativ, ¨oppen upphandling, selektiv upphandling eller f¨orhandlad upp- handling. Under en ¨oppen upphandling f˚ar alla intresserade leverant¨orer l¨amna bud och beslut fattas utifr˚an anbuden utan n˚agon f¨orhandling. Vid en selektiv upphandling bjuder den ink¨opande enheten in leverant¨orer att l¨amna anbud och tar sedan upp f¨orhandlingar med en eller flera av dem. Den startar med en anbudsans¨okan utifr˚an vilken leverant¨orerna som f˚ar l¨amna anbud v¨aljs ut, pr¨ovning och antagande av anbud sker sedan utan f¨orhandling. F¨orhandlad upp- handling liknar selektiv upphandling med skillnaden att antagande av anbud f¨oreg˚as av en f¨orhandling med leverant¨oren. Vidare finns tv˚a huvudprinciper vad g¨aller pr¨ovning av anbud, det ena ¨ar att g˚a efter l¨agsta ink¨opspris medan det andra ¨ar att v¨alja det mest ekonomiskt f¨ordelaktiga priset. I det senare alternativet f˚ar best¨allaren m¨ojlighet att v¨aga in s˚adana omst¨andigheter som t.ex. driftskostnader, funktionalitet etc. dock ska kriterierna f¨or avv¨agningen klarg¨oras vid anbudsf¨orfarandet. Efter en upphandling kan dess beslut bli om- pr¨ovat av en domstol om en leverant¨or eller annan part anser att upphandlingen inte g˚att till p˚a ett korrekt s¨att. (Axelsson, 1998, sid. 282ff)
3.2.2 Upphandling av IT-system
En av de viktigaste uppgifterna f¨or en verksamhetsledning ¨ar att vara insatt i vad verksamheten har f¨or informationsbehov och hur informationsresurser anv¨ands. Ledningen skall vara medveten om verksamhetens nuvarande infor- mationsanv¨andning och informationsteknologi samt ha en tydlig m˚albild f¨or dessa. Styrelse och ledning ansvarar f¨or verksamhetens strategiska m˚als¨attning och m˚aste d¨arf¨or kunna avg¨ora om informationshanteringen ¨ar anpassad till den utveckling som f¨oretaget planerar. (Kurt´en, 2009, sid. 58ff) Kommunikationen mellan ansvariga f¨or verksamheten och ansvariga f¨or informationsteknologin ¨ar ofta d˚alig. IT-ansvariga vet inte exakt vilka informationstj¨anster verksamheten beh¨over samtidigt som verksamhetsansvariga inte vet vilka tj¨anster som finns och b¨or beg¨aras eller hur uppf¨oljning och utv¨ardering av informationstj¨anster ska ske. Styrelse och ledning ska dock inte beh¨ova ha detaljk¨annedom om verk- samhetens tekniska l¨osningar, denna kompetens ligger hos personal och speci- alister som ¨ar n¨ara knutna till dessa. Det ¨ar d¨arf¨or viktigt att man ist¨allet vet vilka fr˚agor som ¨ar viktiga att st¨alla och vilka svar som ¨ar rimliga. (Kurt´en, 2009, sid. 24)
F¨or en verksamhet ¨ar det viktigt att veta vilka potentiella tj¨anster som g˚ar att implementera och vad detta skulle inneb¨ara. Det ¨ar dock s¨allan de verksam- hetsansvariga vet vilka tj¨anster detta ¨ar. De IT-ansvariga som har kunskap om dessa tj¨anster vet ist¨allet inte att verksamheten har ett behov av dem. Anled- ningen ¨ar delvis en spr˚akskillnad mellan dessa tv˚a parter som g¨or det sv˚art att kommunicera effektivt. Resultatet ¨ar att ett best¨allt system inte fyller det behov som var planerat och att best¨allaren inte heller ¨ar beredd p˚a de f¨or¨andringar som det nya informationssystemet medf¨or. (Kurt´en, 2009, sid. 88) Det g˚ar in- te att samla in och ta h¨ansyn till allt som ¨ar relevant, det g˚ar heller inte att analysera alla t¨ankbara alternativ f¨or att i f¨orhand kunna s¨aga vilket som ¨ar minst resurskr¨avande, det handlar om erfarenhet och kompetens. Det ¨ar dessa tv˚a faktorer som till˚ater att viktig information lyfts fram medan ¨ovrigt s˚allas bort utan n¨armare unders¨okning. (Kurt´en, 2009, sid. 89)
Det ¨ar ledningens uppgift att s¨akerst¨alla att investeringar och anskaffningar utg˚ar fr˚an verksamhetens behov. Vid upphandlingar som p˚averkar informations- system kr¨avs mycket kompetens, st¨orre och bredare s˚adan med ¨okad komplexitet p˚a den befintliga informationsstrukturen och med ¨okat beroende p˚a informa- tionssystemen. (Kurt´en, 2009, sid. 80)
3.2.3 Beslutsunderlag
Ett vanligt problem ¨ar sv˚arigheter med att ta fram ett gemensamt beslutsun- derlag, verksamhetsansvariga uttrycker sig i form av vad personalen beh¨over kunna utf¨ora och IT-ansvariga l¨agger fram tekniska specifikationer. Detta kan underl¨attas genom att l˚ata en IT-arkitekt ¨overs¨atta mellan parterna. Det finns dock en risk att best¨allaren ¨overl¨amnar beslutsfattandet ˚at sina IT-ansvariga eller ˚at s¨aljaren vilket med st¨orsta sannolikhet resulterar i ett felaktigt resultat f¨or best¨allaren. I verksamheter med l˚ag IT-mognad ¨ar det som sv˚arast att fatta beslut g¨allande denna typ av fr˚agor. H¨ar ¨ar det viktigt att l˚ata mognadspro- cessen ta viss tid och eventuellt testa sig fram f¨or att undvika st¨orre misstag. I moderna IT-projekt ¨ar det vanligt att anv¨anda sig utav prototyper f¨or att pr¨ova sig fram till ett l¨ampligt system. (Kurt´en, 2009, sid. 92ff)
Som beslutsunderlag b¨or en organisation anv¨anda sig utav de dokument som beskriver verksamhetens informationshantering, d¨aribland allm¨anna prin- ciper f¨or f¨oretagets anv¨andning av informationsteknologi, IT-arkitekturen, IT- infrastrukturen samt applikations- och informationstj¨anstbehovet. Allm¨anna principer f¨or f¨oretagets IT-anv¨andning omfattar ¨overgripande och v¨agledande beslutsfattande, regler som utformas p˚a h¨og niv˚a i verksamheten. I dessa regler skall det framg˚a om f¨oretaget huvudsakligen skall anv¨anda sig utav standard- system eller om m˚alet skall vara att egenutveckla och skr¨addarsy sina system, hur f¨oretaget skall arbeta med IT och hur IT ska st¨odja verksamheten. IT- arkitekturen utg¨ors av generella specifikationer f¨or hur f¨oretagets informations- system skall byggas upp. H¨ar skall det framg˚a vilka standarder f¨oretaget ska f¨olja, hur informationstj¨anster och IT-processer ska anpassas efter verksamheten och andra processer. IT-infrastrukturen definierar f¨oretagets informations- och kommunikationstj¨anster. Det skall h¨ar framg˚a vilka applikationer som anv¨ands, hur rutiner f¨or kommunikation ¨ar utformade, hur data lagras, samt mjukare fr˚agor s˚asom r¨orande s¨akerhets- och arkiveringsrutiner. Applikationsbehovet och konkreta informationstj¨anster skapar direkt v¨arde f¨or f¨oretaget vid anv¨andning och skall st¨odja f¨oretagets processer. (Kurt´en, 2009, sid. 94ff)
Kravst¨allning handlar om att definiera vad systemet ska och b¨or kunna g¨ora utifr˚an verksamhetens behov. Det ¨ar viktigt att ha v¨aldefinierade krav f¨or ett lyckat resultat. Med en bra kravst¨allning redan fr˚an b¨orjan kan man undvi- ka missf¨orst˚and och fel senare i projektet vilket skulle kunna kosta b˚ade tid och pengar. (Eriksson, 2007, sid. 17ff) Det handlar om att i ett tidigt skede klarg¨ora vad systemet ska utf¨ora och p˚a vilket s¨att, f¨or att f˚a ett anv¨andbart
och anv¨andarv¨anligt system. (Eriksson, 2007, sid. 41ff) F¨or att skapa en bra kravst¨allning handlar det om att samla in krav fr˚an intressenter som ¨ar repre- sentativa f¨or olika delar av verksamheten. Vidare g¨aller det att strukturera och prioritera dessa krav f¨or att l¨att kunna se hur kraven kommer att p˚averka ar- betet med systemet. (Eriksson, 2007, sid. 29ff) Syftet med att prioritera sina krav ¨ar att hitta de mest betydelsefulla kraven. Prioriteringen b¨or ske utifr˚an vad som ¨ar b¨ast f¨or verksamheten och anv¨andarna men ¨aven med avseende p˚a kunskap om kostnad och risker f¨or genomf¨orandet. (Eriksson, 2007, sid. 11) Till att b¨orja med brukar man dela upp kraven i funktionella och ickefunktionella krav, d¨ar funktionella krav beskriver vad systemet ska kunna utf¨ora och icke- funktionella krav klarg¨or hur det ska fungera. (Eriksson, 2007, sid. 43ff) Det
¨ar sedan vanligt att prioritera sina krav utifr˚an ska och b¨or, d¨ar ska-krav ¨ar s˚adana som ¨ar absolut n¨odv¨andiga medan b¨or-krav ¨ar ¨onskem˚al som f¨orv¨antas uppfyllas om det ¨ar genomf¨orbart. (Eriksson, 2007, sid. 105)
3.3 Teoretiskt ramverk
Teorin syftar till att redog¨ora f¨or den komplexitet som finns i en upphandling av aff¨arssystem och vad det st¨aller f¨or kompetenskrav p˚a en verksamhet som best¨allare. Det ¨ar komplext i det avseende att best¨allaren m˚aste ta h¨ansyn till m˚anga faktorer som spelar in s˚asom verksamhetens behov och kunskap om det nya systemet samt befintliga system. En ink¨opsprocess handlar om att f¨orst˚a vad behovet ¨ar, vilka l¨osningar som finns, vad de olika l¨osningarna inneb¨ar och sedan att v¨alja en l¨osning. Den ink¨opande verksamheten m˚aste utifr˚an k¨opets f¨oruts¨attningar organisera en ink¨opsfunktion som hanterar dessa aspek- ter g¨allande ink¨opet och det ¨ar samordning av denna kompetens som utg¨or en verksamhets best¨allarkompetens.
Aven ink¨¨ op av aff¨arsystem ¨ar komplext eftersom det ut¨over sj¨alva produkten i regel ¨aven kr¨avs tj¨anster f¨or implementation och framtida drift. Detta inneb¨ar att ink¨opsprocessen st¨aller h¨oga krav p˚a verksamhetens best¨allarkompetens f¨or att resultatet av en upphandling ska bli ett aff¨arssystem som uppfyller verksam- hetens behov. Eftersom en offentlig upphandling ¨ar l˚ast n¨ar den v¨al ¨ar p˚ab¨orjad
¨ar det i praktiken f¨orarbetet till upphandlingen som avg¨or vilken leverant¨or som utses till vinnare, detta inneb¨ar att upphandlingen och dess f¨orberedelser
¨ar v¨aldigt avg¨orande f¨or en verksamhet i offentlig sektor.
Verksamheten m˚aste f¨orst f¨orst˚a problemen med den nuvarande l¨osningen innan ett behov kan specificeras. Behovet m˚aste grundas utifr˚an hela verk-
samheten och inte begr¨ansas till ett tekniskt perspektiv genom att utg˚a fr˚an verksamhetens processer, rutiner och regler f¨or att precisera behovet. D˚a ett aff¨arssystem ska fungera i det befintliga informationssystemet ¨ar det viktigt att upphandlingen grundar sig i verksamhetens m¨anskliga aktiviteter och det infor- mationsbehov som finns d¨ar. Om ett ink¨op av informationsteknologi sker utan detta som utg˚angspunkt kommer det sociotekniska systemet i slut¨andan inte att fungera som t¨ankt och det ¨ar d¨arf¨or viktigt att best¨allarkompetensen finns med redan fr˚an b¨orjan under ink¨opsprocessen. F¨or att kunna f¨orst˚a och avg¨ora vilka l¨osningar som kan fungera i det befintliga informationssystemet utifr˚an b˚ade ett socialt och tekniskt perspektiv m˚aste best¨allarkompetens byggas upp med hj¨alp av b˚ade IT-avdelningen och verksamheten i ¨ovrigt. IT-avdelningen ska kunna bist˚a med den informationsteknik som verksamheten beh¨over men f˚ar inte p˚a egen hand v¨alja l¨osning.
N¨ar behovet ¨ar fastst¨allt kan sedan aff¨arssystem unders¨okas f¨or att f˚a en uppfattning om hur systemen fungerar och vad det finns f¨or alternativ, vad
¨
overg˚angen till ett aff¨arssystem inneb¨ar och de problem som kan uppst˚a. Det
¨ar ¨aven viktigt att f¨orst˚a hur verksamheten och aff¨arssystemet ska fungera till- sammans f¨or att kunna genomf¨ora en lyckad implementation och uppn˚a den efters¨okta l¨osningen. Verksamheten m˚aste vara beredd p˚a de f¨or¨andringar som systemet medf¨or och det g¨aller d¨arf¨or att vara insatt i vilket tillv¨agag˚angss¨att verksamheten ¨ar mottaglig f¨or.
Upphandlingsunderlaget ska sedan beskriva verksamhetens behov och p˚a ett tydligt s¨att redog¨ora f¨or hur ett aff¨arssystem ska tillfredsst¨alla dessa.
Kravst¨allning ¨ar h¨ar en viktig del av upphandlingen d˚a det avg¨or vad det tillt¨ankta systemet m˚aste uppfylla. Den st¨orsta utmaningen med en offentlig upphandling ¨ar att sammanst¨alla ett underlag som preciserar verksamhetens behov. Underlaget m˚aste vara uppbyggt p˚a ett s˚adant s¨att att det framg˚ar vilket resultat verksamheten f¨orv¨antar sig och vilka krav detta st¨aller p˚a leverant¨oren.
Verksamheten & aff¨arssystem Upphandling
Figur 1: Best¨allarkompetens under ink¨opsprocessen av aff¨arssystem
Figur 1 illustrerar en modell f¨or best¨allarkompetens vid upphandling av ett aff¨arssystem. Best¨allarkompetens representeras av den ¨ovre pilen och beskrivs i de nedanst˚aende pilarna utifr˚an den ink¨opsprocess som sker och de tre huvud- omr˚aden den best˚ar av, verksamheten, aff¨arssystemet och upphandlingen.
Den f¨orsta av dessa pilar betecknar den f¨orsta fasen i ink¨opsprocessen av ett aff¨arssystem d¨ar den ink¨opande organisationen utifr˚an sitt behov unders¨oker de aff¨arssystem som ¨ar potentiella l¨osningar. F¨or att avg¨ora om ett aff¨arssystem uppfyller verksamhetens behov m˚aste kunskapen om aff¨arssystem ¨okas. Det finns h¨ar en ˚aterkoppling mellan behovet och l¨osningen eftersom behovet baseras p˚a verksamheten och l¨osningen i detta fall ¨ar ett aff¨arssystem. Denna ˚aterkoppling symboliserar att ¨okad kunskap om verksamhetens behov p˚averkar bed¨omningen av ett aff¨arssystem som l¨osning och ¨okad kunskap om aff¨arssystem p˚averkar verksamhetens syn p˚a sitt behov.
Den andra pilen representerar sj¨alva upphandlingen som ¨ar den andra fasen och inneb¨ar att verksamheten utifr˚an den kunskap som byggts upp om verk- samheten och aff¨arssystem som l¨osning framst¨aller ett underlag f¨or att kunna genomf¨ora en upphandling i syfte att v¨alja den l¨osning som ¨ar b¨ast l¨ampad att tillfredsst¨alla verksamhetens behov.
Best¨allarkompetens byggs p˚a detta s¨att upp utifr˚an den kunskap verksam- heten tillgodog¨or sig under dessa tv˚a faser.
4 Metod
Detta avsnitt syftar till att f¨orklara hur vi har genomf¨ort v˚ar unders¨okning.
Metodavsnittet inleds med att utifr˚an den teoretiska referensramen redog¨ora f¨or vilka metoder och tillv¨agag˚angss¨att som vi anv¨ant f¨or att angripa problemet. Det avslutas sedan med en redog¨orelse f¨or vad unders¨okningen i sig kan komma att bidra med utifr˚an metodvalet.
4.1 Hur den teoretiska referensramen anv¨ ands
V˚ar teoretiska referensram behandlar hur arbetet med informationssystem i en verksamhet och f¨orv¨arvandet av nya system fungerar. Den syftar till att ge en bild av de omr˚aden under ink¨opsprocessen som ¨ar essentiella f¨or best¨allarkompetens vid upphandling av ett nytt aff¨arssystem. Utifr˚an denna referensram har vi unders¨okt hur en offentlig verksamhet kunnat tillgodog¨ora sig den kunskap som kr¨avs f¨or att upphandla ett nytt aff¨arssystem med en ef- ters¨okt funktionalitet. (Holme and Solvang, 1997, sid. 47ff) Detta har gjorts genom att studera den upphandlingsprocess Kronofogden bedrev vid upphand- ling av ett nytt system f¨or medelshantering. Vi har unders¨okt hur Kronofogden har hanterat behovet av kompetens under de tv˚a faser modellen beskriver. Det var h¨ar intressant att f˚a veta om kompetens saknades i den egna verksamhe- ten inf¨or upphandlingen och hur Kronofogden kompleterade denna eventuellt saknade kompetens.
4.2 Hur unders¨ okningen har genomf¨ orts
Vi har valt att anv¨anda oss av kvalitativ metod eftersom v˚art syfte kr¨aver en f¨orst˚aelse f¨or just den upphandlingsprocess som Kronofogden bedrivit. F¨or att kunna f˚a denna f¨orst˚aelse har datainsamling genomf¨orts via intervjuer med per- soner involverade i upphandlingen och genom att samla in offentliga handlingar och arbetsmaterial relaterade till upphandlingen. (Holme and Solvang, 1997, sid. 76)
F¨or att f˚anga involverade personers erfarenheter och upplevelser av att ing˚a i projektet genomf¨ordes totalt elva intervjuer med elva personer som p˚a olika s¨att var insatta i upphandlingsprojektet. Det handlade i huvudsak om personer fr˚an projektets beslutsgrupp men ¨aven leverant¨orerna SAP och Oracle:s perspek- tiv var h¨ar intressant. (Kvale, 1997, sid. 37) Beslutsgruppen bestod f¨orutom Kronofogden av anst¨allda p˚a Skatteverket samt Verksamhetsst¨od (VE) som ¨ar
leverant¨or av drift- och st¨odtj¨anster till de ¨ovriga tv˚a. Skatteverket represen- terades av en person fr˚an IT-staben som ¨ar den stab som har ett strategiskt ansvar f¨or Kronofogden och Skatteverkets IT-milj¨oer. (W¨asterlid, 2009) Vida- re studerades ¨aven skriftligt underlag r¨orande upphandlingen, sj¨alva upphand- lingsf¨orfr˚agan samt arbetsmaterial bakom den. Vi har p˚a s˚a s¨att unders¨okt hur Kronofogden har f¨orberett och genomf¨ort sin upphandling samt bakgrunden till de beslut som tagits. Vi har d¨arefter applicerat v˚ar modell f¨or att analysera best¨allarkompetensen i samband med upphandlingsprojektet utifr˚an det teo- retiska ramverket. Vidare analys genomf¨ordes sedan i syfte att lyfta fram de faktorer som spelat mest roll f¨or Kronofogden och p˚a vilket s¨att dessa har han- terats, s˚asom vilka delar av upphandlingen som bed¨omdes vara viktigast och vad som gjordes f¨or att s¨akerst¨alla best¨allarkompetensen. (Holme and Solvang, 1997, sid. 59)
De genomf¨orda intervjuerna var semistrukturerade och h¨olls i samtalsform d¨ar vi anv¨ande oss av ett antal tematiska fr˚agest¨allningar anpassade efter re- spektive intervjuperson. (Kvale, 1997, sid. 32) Ut¨over detta formulerades ¨aven fr˚agor f¨or att t¨acka upp eventuella luckor och f¨or att f˚a svar p˚a fr˚agor som vi ans˚ag relevanta men som inte framst˚ar som centrala i v˚ar teori. Intervjufr˚agorna f¨or respektive intervjuperson ˚aterfinns i bilaga A.
4.2.1 Intervjuplanering
I v˚ar modell har vi valt ut de faser inom ink¨opsprocessen f¨or aff¨arssystem som ¨ar mest relevanta att unders¨oka f¨or best¨allarkompetens. Vi har i huvudsak utg˚att fr˚an dessa omr˚aden n¨ar vi valt ut intervjupersoner men genomf¨orde ¨aven inter- vjuer med leverant¨orernas s¨aljare f¨or att f˚a ett annat perspektiv p˚a upphandling- en. Inledningsvis intervjuades relevanta personer fr˚an projektets beslutsgrupp och d¨arefter tillkom ytterliggare personer som p˚a olika s¨att var knutna till upp- handlingsprojektet. Leverant¨orerna intervjuades under slutet av unders¨okningen f¨or att inte p˚a f¨orhand f¨arga v˚ar inst¨allning och p˚averka de tidigare intervjuerna.
Vi har till stor del genomf¨ort respondentintervjuer men det f¨orekom ¨aven ett f˚atal gruppintervjuer. Intervjuerna har med ett enskilt undantag genomf¨orts p˚a eller i n¨arheten av intervjupersonernas respektive arbetsplats vilket givit oss en b¨attre insyn i deras arbete samtidigt som det skapat en bekv¨amare intervjumilj¨o f¨or intervjupersonerna.
4.3 Unders¨ okningens trov¨ ardighet
Unders¨okningen ¨ar en kvalitativ studie med fokus p˚a upphandling av ett aff¨arssystem hos en myndighet. I egenskap av att komma fr˚an en myndighet
¨ar mycket av den information vi samlat in t¨ackt av offentlighetsprincipen och
¨ar med andra ord offentliga handlingar. Upphandlingen i sig ¨ar en offentlig upphandling och har d¨arf¨or genomf¨orts i enlighet med lagen om offentlig upp- handling, detta inneb¨ar att dess riktighet kan ifr˚agas¨attas och ogiltigf¨orklaras av en domstol. Det ¨ar d¨arf¨or viktigt f¨or den upphandlande myndigheten att underlaget till upphandlingen ¨ar korrekt. P˚a grund av detta ¨ar muntlig infor- mation och de arbetsmaterial vi tagit del av det enda vars riktighet inte kan kontrolleras direkt av utomst˚aende. (Holme and Solvang, 1997, sid. 131)
D˚a unders¨okningen enbart utg˚ar fr˚an en enskild myndighet kan inte resulta- ten anses vara generaliserbara f¨or andra offentliga verksamheter eller offentliga upphandlingar. D¨aremot hoppas vi att resultatet bidrar till en b¨attre uppfatt- ning om vad en offentlig verksamhet beh¨over ta h¨ansyn till n¨ar den ska upp- handla aff¨arssystem.
5 Empiri
Detta avsnitt syftar till att f¨ormedla vad som kommit fram genom det material som samlats in f¨or denna uppsats. Avsnittet inleds med kort historik om Kro- nofogden samt en bakgrund till deras upphandling, d¨arefter f¨oljer en kronologisk redog¨orelse f¨or hur Kronofogden har g˚att tillv¨aga vid genomf¨orandet av sin upp- handling. Avsnittet avslutas med en redog¨orelse f¨or SAP och Oracle:s reflektio- ner p˚a Kronofogdens upphandling och deras erfarenheter av best¨allarkompetens inom offentlig sektor vid ink¨op av aff¨arssystem.
5.1 Kronofogdemyndigheten
Kronofogdens verksamhet handlar i huvudsak om att fastst¨alla och driva in statliga och privata skulder, men de arbetar ¨aven med f¨orebyggande verk- samhet, skuldsanering samt konkurstillsyn. Arbetet med indrivning av skul- der ¨ar den st¨orsta delen av verksamheten och handlar om inbetalningar fr˚an omkring 500 000 g¨alden¨arer och utbetalningar till ca 100 000 borgen¨arer.
F¨ordelningen av pengar fr˚an g¨alden¨arer till borgen¨arer sk¨ots i dagsl¨aget av sy- stemet REX.(W¨asterlid, 2009)
REX togs i drift 1975 och ¨ar ett egenutvecklat system som ¨ar uppbyggt och anpassat efter den dagliga verksamheten. Det har med ˚aren vidareutvecklats efter behov och ¨ar efter ¨over 30 ˚ar i dagsl¨aget s˚a gott som fritt fr˚an “buggar”.
Nackdelen och risken med REX ¨ar att systemet bygger p˚a gammal teknik och har d¨arf¨or blivit ett hinder f¨or verksamhetsutvecklingen. Kronofogden har sj¨alva gjort tre f¨ors¨ok att utveckla ers¨attare till REX, dessa f¨ors¨ok har av olika anled- ningar misslyckats. (Persson, 2009) Det sista f¨ors¨oket till att egenutveckla en ers¨attare till REX gjordes runt ˚ar 2000. Detta f¨ors¨ok byggde p˚a en strategi runt successiv utveckling, att byta ut systemets delar i olika etapper d¨ar medelshan- teringen var den f¨orsta delen att bytas. Strategin togs fram f¨or att undvika att upprepa tidigare misslyckanden d˚a man f¨ors¨okt byta ut hela systemet p˚a sam- ma g˚ang. Projektet l¨aggs dock ner p˚a grund av att det blir f¨or sv˚arhanterligt.
(Lindgren, 2009)
5.1.1 F¨orunders¨okning
F¨or omkring fyra ˚ar sedan kom fr˚agan om systembyte upp igen, men denna g˚ang fr˚agade man sig om medelshantering var n˚agot som borde egenutvecklas
¨overhuvudtaget. Trots att det ¨ar en begr¨ansad del av REX ans˚ags det vara f¨or
stort f¨or dem att klara av sj¨alva. Kronofogden startade en utredning om vad som hade h¨ant med det sista f¨ors¨oket till egenutveckling och om det fortfaran- de var en m¨ojlighet. Senaste f¨ors¨oket hade precis som de tidigare resulterat i f¨orlorad investering och uteblivna nyttoint¨akter. F¨or att genomf¨ora utredningen anlitades konsulter fr˚an Capgemini. (B¨orjesson, 2009; Sj¨osten, 2009)
Kronofogden v¨ande sig ¨aven till IT-staben (IT-staben har ett strategiskt stabsansvar f¨or b˚ade Kronofogden och Skatteverkets IT-milj¨oer) med fr˚agan om inte ett standardsystem kunde vara l¨osningen. IT-staben h¨oll med om att det var en m¨ojlighet och s˚ag ¨aven att ett standardsystem kunde vara en l¨osning f¨or Skatteverkets framtida systembyte. (Lindgren, 2009) V˚aren 2007 b¨orjar de unders¨oka saken n¨armare och det fanns tv˚a stora intressen, medelshantering f¨or Kronofogden samt Skatteverkets s˚akallade skattekonto. Kronofogden hade
¨aven ¨arendehanteringsdelen hos REX som ett sekund¨art intresse d˚a detta var n¨asta del att bytas ut efter medelshanteringen. Eftersom de sj¨alva inte hade n˚agon erfarenhet fr˚an standardsystem sedan tidigare best¨amde man sig f¨or att upphandla konsulttj¨anster f¨or r˚adgivning under unders¨okningen och Capgemini blev leverant¨or ¨aven till denna unders¨okning. (B¨orjesson, 2009; Sj¨osten, 2009)
Inledningsvis skedde en omv¨arldsbevakning f¨or att se vilka system p˚a mark- naden som kunde uppfyllde kraven f¨or systemets omfattning och funktionali- tet. Detta resulterade i tv˚a leverant¨orer med intressanta l¨osningar som man d˚a besl¨ot sig f¨or att unders¨oka n¨armare. H¨osten 2007 b¨orjade respektive system unders¨okas f¨or att reda ut inf¨orandeplan, kostnadskalkyl och en riskanalys. De b¨orjade ¨aven titta p˚a den egna verksamheten f¨or att se hur mogen organisatio- nen var f¨or eventuell f¨or¨andring. Efter att ha tittat p˚a enklare demonstrationer av systemen best¨amde sig Kronofogden f¨or att unders¨oka referenser f¨or att f˚a en b¨attre uppfattning om hur aff¨arssystemen fungerar i praktiken. Det blev tre studieresor till verksamheter som motsvarade Skatteverket och Kronofogden f¨or att se hur deras projekt var upplagda. (B¨orjesson, 2009; Sj¨osten, 2009)
P˚a Holl¨andska skatteverket DTA (Dutch Tax Agency) p˚agick deras aff¨arssystemsprojekt fortfarande. Upphandlingen avslutades v˚aren 2005 efter en utv¨ardering mellan SAP, Oracle och SPL. De lade stor vikt vid prototyping under upphandlingen och betalade de tre leverant¨orerna f¨or att bygga varsin protoyp till ett antal f¨orutbest¨amda anv¨andningsfall. Utv¨arderingens resultat visade att SPL kunde leverera b¨ast system och ett avtal sl¨ots med denna le- verant¨or. SPL blev sedan uppk¨opta utav Oracle ˚aret d¨arp˚a, men det s˚ag man bara som positivt d˚a Oracle ¨ar ett mycket st¨orre f¨oretag ¨an SPL. Det ¨ar ¨an s˚a l¨ange ingen del av systemet som tagits i drift d˚a man underskattade analysfasen
f¨or systemet, men ¨aven p˚a grund av att SPL blev uppk¨opta. ¨Aven om projektet
¨ar f¨orsenat har DTA fullt f¨ortroende f¨or l¨osningen och bed¨omer produkten som den klart b¨asta man tittat p˚a. (IT-staben, 2007)
Det danska skatteverket SKAT har haft SAP som redovisningssystem sedan 1998. SKAT h˚aller f¨or n¨arvarande p˚a med utvecklingen av ett projekt i SAP som liknar Kronofogdens. Man har en renodlad SOA-arkitektur och SAP ¨ar d¨ar ett utav flera system vilket medf¨or att SKAT medvetet valt bort SAP:s processer och plattformsl¨osningar f¨or att endast anv¨anda grundfunktionaliteten.
SKAT g¨or en pr¨ovning av vilka grundsystem som skall utnyttjas varje g˚ang ett nytt IT-st¨od beh¨ovs vilket inneb¨ar att de k¨or en BoB-strategi n¨ar det g¨aller standardssystem. (IT-staben, 2007)
Hos FDOR (Florida Department of Revenue) anv¨ands SAP f¨or bland annat skattekonto, indrivning och medelshantering. De har en n¨astan fullskalig SAP- strategi som best˚ar till 95% av SAP-applikationer. Projektet startade i slutet p˚a 90-talet efter flera misslyckade f¨ors¨ok med egenutveckling samt BoB-l¨osningar till att f¨ornya flera gamla stordatorsystem. Projektets framg˚ang beror till stor del p˚a att det hela tiden har drivits av verksamheten och inte IT. (IT-staben, 2007)
F¨or alla tre verksamheterna hade det f¨orefallit naturligt att v¨alja ett stan- dardsystem. Ingen av dem hade genomf¨ort n˚agon kostnadskalkyl, j¨amf¨orande egenutveckling och standardsystem. (B¨orjesson, 2009; Sj¨osten, 2009)
Fr˚an studieresorna fick Kronofogden en insyn i den komplexitet som ett aff¨arssystem medf¨or och vad som var viktigt att t¨anka p˚a vid ett s˚ant projekt.
Till att b¨orja med ¨ar det viktigt att ha en plan med projektet och det kan vara l¨ampligt att anv¨anda en BoB-strategi, f¨or att sedan successivt ¨oka anv¨andningen av systemet till flera omr˚aden om det beh¨ovs. Genom att ha en v¨alplanerad ar- kitektur ¨over hur verksamhetens informationssystem ska se ut kan man styra hur aff¨arssystemet ska anv¨andas. Inf¨or upphandlingen ¨ar det viktigt att vara pragmatisk i kravst¨allandet f¨or att undvika ”bra-att-ha”-krav. Inf¨or implemen- tationen m˚aste leverant¨orerna f˚a en djup insikt i aktuella verksamhetsprocesser s˚a att systemet i slut¨andan uppfyller de krav som finns.
Det ¨ar viktigt att verksamheten l¨ar sig produkten redan innan utveck- lingen p˚ab¨orjas d˚a det ¨ar verksamhetsprocessen som styr utvecklingen. Om man anv¨ander sig utav prototyping vid inf¨orskaffandet utav ett aff¨arssystem
¨ar det viktigt att ge konkreta uppdrag avseende det, f¨or att leverant¨oren ska f˚a en bra bild av den kompetens som beh¨over mobiliseras fr˚an deras sida. (IT- staben, 2007)
5.1.2 Beslut om upphandling
Den f¨orsta januari 2008 blev Kronofogdemyndigheten en frist˚aende statlig myn- dighet, tidigare var Kronofogdemyndigheten en del av Skatteverket. Det beslu- tades samtidigt att Kronofogden ska forts¨atta anv¨anda Verksamhetsst¨od, VE, f¨or allt behov av drift och supportfunktioner fram till 2012. Verksamhetsst¨od
¨ar en st¨odenhet som levererar st¨odtj¨anster till Kronofogden och Skatteverket.
(W¨asterlid, 2009)
De tv˚a unders¨okningarna avslutades och Capgemini presenterade tv˚a f¨orslag p˚a hur de kunde byta ut REX utifr˚an de tv˚a unders¨okningarna. Det var tv˚a alternativ att v¨alja mellan, antingen egenutveckling eller standardsystem och b˚ada l¨osningarna baserades p˚a att Capgemini skulle genomf¨ora projektet. Kro- nofogden avb¨ojde b˚ada f¨orslagen f¨or att ist¨allet genomf¨ora en upphandling.
(Persson, 2009)
Beslutet berodde i huvudsak p˚a att man inte ville ¨overl˚ata ett system- byte helt till konsulter och d¨arigenom hamna i ett beroende gentemot en le- verant¨or. N¨ar unders¨okningarna hade b¨orjat var F¨ors¨akringskassan mitt uppe i sitt systembyte till SAP och projektet fortl¨opte enligt deras ursprungliga plan vilket bidrog till uppfattningen att ett standardsystem f¨ormodligen var r¨att v¨ag ¨aven f¨or Kronofogden. Senare b¨orjade Kronofogden h¨ora mer och mer oro- ligheter om F¨ors¨akringskassans systembyte och man fick indikationer p˚a att F¨ors¨akringskassan inte l¨angre hade kontroll ¨over utvecklingen av systemet. En annan anledning till att Kronofogden tackade nej till ett fortsatt samarbete med Capgemini var att relationen mellan VE och Capgemini hade b¨orjat f¨ors¨amras under ett samarbete. Det framstod d¨arf¨or som ol¨ampligt att ta in Capgemini som leverant¨or av ett helt aff¨arssystem. (B¨orjesson, 2009; Sj¨osten, 2009)
Kronofogden best¨amde att ett aff¨arssystem var l¨osningen f¨or att byta ut REX, men att de skulle b¨orja med medelshantering som prim¨art fokus. Ef- tersom de aldrig inf¨ort ett aff¨arssystem tidigare best¨amde man sig f¨or att g¨ora inf¨orandet stegvis. Genom att anv¨anda ett testsystem skulle man d˚a kunna l¨ara sig hur systemet fungerade och bygga upp en kompetens kring systemet.
(Persson, 2009)
5.2 Upphandlingsprojektet
Upphandlingsprojektet startades av Kronofogden efter beslutet om att g˚a ut i en upphandling. Det ¨ar vanligtvis VE som genomf¨or upphandlingar och k¨oper in produkter eller tj¨anster, men i detta fall genomf¨ordes upphandlingen tillsam-
mans med Kronofogden. Detta g¨or att upphandlingsprojektet har best˚att utav personer fr˚an b˚ada dessa organisationer men ¨aven personal fr˚an Skatteverket har medverkat d˚a de ¨ar intresserade utav systemet ifall det blir ett alternativ f¨or dem. Ansvariga f¨or projektet ¨ar en s˚a kallad styrgrupp best˚aende av de che- fer som ansvarar f¨or IT-system hos Kronofogden. Projektgruppen utformades med representanter fr˚an b˚ade Kronfogden och VE f¨or att t¨acka in behovet f¨or b˚ade det tekniska och det verksamhetsspecifika. ¨Aven en beslutsgrupp kom till som ett mellanskikt mellan styrgruppen och projektet f¨or att man i projektet inte skulle beh¨ova fr˚aga styrgruppen om beslut i sm˚afr˚agor utan sj¨alva kun- na fatta dessa och sedan skapa ett underlag f¨or st¨orre beslut till styrgruppen.
(W¨asterlid, 2009)
Beslutsgruppen var en sammans¨attning av personal/experter med ansvar f¨or ett visst intresseomr˚ade r¨orande systembytet. Gruppen tillsattes av upphand- lingens projektledare som ett extra led mellan styrgruppen och upphandling- en. Projektledaren var d˚a nyanst¨alld hos Kronofogden och kom tidigare fr˚an n¨aringslivet. Hon tilldelades upphandlingsprojektet p˚a grund av sin erfarenhet av tekniska upphandlingsprojekt. (W¨asterlid, 2009) ¨Aven ink¨oparen med an- svar f¨or upphandlingen fr˚an VE:s ink¨opsavdelning var medlem i beslutsgruppen.
D˚a de inte tidigare upphandlat aff¨arssystem fanns inte denna kompetens men ink¨oparen hade d¨aremot bedrivit mycket annan teknisk upphandling r¨orande telecom, serverar och lagring. (K¨arger, 2009)
5.2.1 Underlaget
Med lagen om offentlig upphandling ligger den st¨orsta problematiken i att veta exakt vad som ska best¨allas. Det ¨ar underlaget f¨or upphandlingen som beskriver behovet och det ¨ar framf¨orallt kravspecifikationen som best¨ammer resultatet.
Vid upphandlingen ˚ateranv¨andes mycket material fr˚an samarbetet med Capge- mini som bland annat tagit fram en m˚alarkitektur i samarbete med VE. Den togs fram f¨or att standardisera processer och funktionalitet utifr˚an verksam- heten. (B¨orjesson, 2009; Sj¨osten, 2009) Arkitekturen f¨or Kronofogdens system bygger p˚a en SOA-struktur med befintliga system och det nya f¨or medelshante- ring. (W¨asterlid, 2009)
Vid utformningen av kravspecifikationen arbetade man mycket med att tona ned verksamhetskrav och ist¨allet l¨agga mer fokus p˚a underh˚all och standardi- sering. Ansvaret f¨or kravspecifikationen l˚ag p˚a projektledaren och de experter som framst¨allde krav f¨or sina respektive omr˚aden. Resultatet blev ˚atta ska-krav
utav totalt omkring 300 krav. Kronofogden var avsiktligen v¨aldigt ˚aterh˚allsam med ska-krav och “bra att ha”-krav d˚a kravspecifikationen ¨ar avg¨orande f¨or hur m˚anga leverant¨orer som kan svara p˚a upphandlingen. Underlaget till kravspeci- fikationen bestod bland annat av en gammal kravspecifikation fr˚an f¨ors¨oket att byta ut REX ˚ar 2000, samt material som togs fram under samarbetet med Cap- gemini. Kronofogden var medveten om risken att alla krav inte skulle bli r¨att formulerade d˚a det var f¨orsta standardsystemet man upphandlade. Eftersom man tidigare egenutvecklat sina system inneh¨oll dessa kravspecifikationer ex- empelvis inga krav p˚a dokumentation, implementation eller drift. F¨or att f˚a en b¨attre insyn i hur man kravst¨allde ett aff¨arssystem anv¨ande sig Kronofogden bland annat utav den kravspecifikation som F¨ors¨akringskassan framst¨allt till sin upphandling. F¨ors¨akringskassans upphandling resulterade i endast en svarande leverant¨or vilket Kronofogden inte ville upprepa, men upphandlingen inneh¨oll
¨aven bra saker att dra l¨ardomar ifr˚an.(W¨asterlid, 2009)
5.2.2 Upphandlingen
Upphandlingen innefattade ett ramavtal, en testlicens samt ett utv¨arderingsprojekt med option att forts¨atta med det fullst¨andiga aff¨arssystemet. Ramavtalet inneh˚aller m¨ojligheterna att avropa funktio- ner f¨or kund- och personalhantering, samt att Skatteverket kan avropa samma aff¨arssystem f¨or sin verksamhet. Fr˚an b¨orjan fanns det l¨ange med i planeringen att kravst¨alla fler delsystem, men enligt proportionalitetsprincipen f˚ar man endast kravst¨alla just den produkt eller tj¨anst som skall upphandlas. Detta gjorde att upphandlingen fick begr¨ansas till funktionerna som prioriterades h¨ogst. (K¨arger, 2009)
Uppl¨agget f¨or upphandlingen var delvis inspirerat fr˚an studiebes¨oket i Hol- land med skillnaden att man d¨ar utv¨arderade flera system parallellt. Krono- fogden ans˚ag dock att det inte skulle vara bra f¨or varken Kronofogden eller leverant¨orerna att ha tv˚a testsystem involverade samtidigt. Anledningen var att det skulle kr¨ava dubbelt s˚a mycket resurser och man var os¨aker p˚a vad tes- terna skulle resultera i d˚a man ville bygga upp ett samarbete med leverant¨oren och inte se en t¨avling mellan dem. Det skulle ¨aven uppst˚a problem med att ut- forma upphandlingen till att innefatta tv˚a system, eftersom ett annat uppl¨agg kr¨avts d¨ar utv¨arderingen ist¨allet hade blivit en avancerad demonstration innan upphandlingen. (W¨asterlid, 2009) Om man utv¨arderar ett system innan upp- handling ¨ar det sedan inte s¨akert att man kan genomf¨ora en upphandling f¨or att
f˚a den leverant¨or som gjorde b¨ast ifr˚an sig under utv¨arderingen. (K¨arger, 2009) Upphandlingen drevs i form av en f¨orhandlad upphandling f¨or att f˚a m¨ojligheten att diskutera med leverant¨orerna innan upphandlingen om det skul- le framkomma att andbudsans¨okan var missvisande. Kronofogden gick ut med en anbudsans¨okan i oktober 2008 som besvarades av leverant¨orerna Oracle och SAP, d¨arefter gick man vidare med anbudsf¨orfarandet och skickade ut upphand- lingsunderlaget till b˚ada leverant¨orerna i december samma ˚ar. En utv¨ardering av leverant¨orernas anbud p˚ab¨orjades i februari 2009 och beslutet om vinnan- de leverant¨or togs i slutet av juni samma ˚ar. B˚ada leverant¨orerna uppfyllde de st¨allda kraven och var d¨armed likv¨ardiga men Oracle uts˚ags som vinnare eftersom denna leverant¨or erbj¨od det ekonomiskt mest f¨ordelaktiga anbudet.
(Kronofogden, 2009)
5.2.3 Utv¨arderingsprojektet
Utv¨arderingen ¨ar det delprojekt som startade efter att sj¨alva upphand- lingsf¨orfarandet avslutades och p˚agick i tre m˚anader under h¨osten 2009. VE fick i uppdrag av Kronofogden att utv¨ardera det testsystem som upphandlats.
Resultatet fungerar sedan som underlag till det beslut som ska fattas mot slu- tet av 2009 ang˚aende inf¨orandet av aff¨arssystemet. (W¨asterlid, 2009) Projektet bestod av tv˚a parallella projektledare, en fr˚an VE och en fr˚an leverant¨oren, samt ca sex personer fr˚an vardera verksamhet. M˚alet ¨ar att f¨ors¨oka beh˚alla samma personal inom projektet om det g˚ar vidare. (Bramson, 2009; Johans- son, 2009) Det ¨ar d¨arf¨or ¨aven bra fr˚an leverant¨orens sida att ha ett testsy- stem, att samma personal blir kvar f¨or att vidh˚alla kunskap och kompetens om just denna implementation. (Rutherhill, 2009) F¨orsta konfigurationen g¨ors med konsulter men drift och dagliga uppgifter skall sedan ligga p˚a egen personal.
(Bramson, 2009; Johansson, 2009)
M˚alet med utv¨arderingen ¨ar, f¨orutom att skapa grunden till en egen kompe- tens g¨allande systemet, ¨aven att utv¨ardera systemet gentemot kravst¨allningen och m˚alarkitekturen f¨or att se hur v¨al det uppfyller sitt syfte. M˚alarkitekturen
¨ar h¨ar central f¨or att veta vad systemet ska g¨ora d˚a systemet m˚aste passa med befintlig arkitektur och infrastruktur. G¨allande kravst¨allningen ¨ar det de icke- funktionella kraven och de har d˚a utg˚att fr˚an kravspecifikationen d¨ar kraven har graderats. (Bramson, 2009; Johansson, 2009)
Ut¨over det som utv¨arderades f¨orbereddes ¨aven den kommande analysfasen, som genomf¨ors om systemet klarar utv¨arderingen. Den innebar att de ¨aven un-
ders¨okte vad som kommer att kr¨avas f¨or att kunna integrera aff¨arssystemet mot befintliga system, huruvida ytterligare licenser beh¨ovs och hur mycket sy- stemet m˚aste anpassas. F¨or att unders¨oka fr˚agor r¨orande integration har en konsult med k¨annedom om integration, arkitektur och aff¨arssystem tagits in f¨or att bist˚a i utv¨arderingen. (Bramson, 2009; Johansson, 2009) Anpassningar till systemet kommer att g¨oras, dock vill man inte beh¨ova g¨ora s˚a omfattan- de anpassningar att det inte g˚ar att uppgradera systemet utan att beh¨ova g¨or om dessa igen. Om inte ca 80% av aff¨arssystemet kan anv¨andas utan anpass- ning anses det inte v¨art att g˚a vidare med aff¨arssystemet, men det ¨ar sv˚art att definiera vad en f¨or¨andring egentligen ¨ar och hur stor den ska anses vara.
(B¨orjesson, 2009; Sj¨osten, 2009) Uppgraderingss¨akra ¨andringar ¨ar i praktiken till¨agg man g¨or som sedan kopplas in i sj¨alva systemet. F¨or en l˚angvarig rela- tion b¨or anpassningar d¨arf¨or ske i form av till¨agg ist¨allet f¨or anpassningar av sj¨alva systemet. Det ¨ar viktigt att f¨olja en standard eftersom det i framtiden antagligen ¨ar andra konsulter som sk¨oter uppgraderingar. (Rutherhill, 2009)
5.3 Leverant¨ orernas reflektioner p˚ a upphandlingen
Offentliga verksamheter som sedan l¨ange bedrivit egenutveckling av IT-system f˚ar ofta problem p˚a grund av detta n¨ar de ska g˚a ¨over till standardsystem. Den etablerade egenutvecklingskulturen leder till att verksamheten inte ens tittar p˚a standardsystem som potentiella l¨osningar utan forts¨atter p˚a samma sp˚ar som tidigare. (Lindberg, 2009) Det ¨ar viktigt att unders¨oka vad som finns p˚a marknaden, verksamheten m˚aste vara ¨oppen och fr˚aga potentiella leverant¨orer vad de har f¨or ˚asikter och synpunkter. (Eriksson, 2009)
Kronofogdens upphandling var en av de b¨attre offentliga upphandlingar leverant¨orerna sett, med ett tydligt underlag och en genomarbetad kravspe- cifikation utan on¨odiga ska-krav. Detta beror till stor del p˚a att Kronofog- den l˚angt i f¨orv¨ag b¨orjat samla in information fr˚an leverant¨orer. D¨aremot var enstaka bed¨omningsfr˚agor sv˚ara att tolka vilket resulterade i diffusa svar.
(Lindberg, 2009; Rutherhill, 2009; Eriksson, 2009)
Kronofogden har definierat en tydlig krav- och m˚albild inf¨or denna upphand- ling, vilket ¨ar bra eftersom det lyfter upp problematik som annars riskerats att f¨orbises. Eftersom REX ¨ar ett stort system hade ett projekt f¨or att byta ut hela systemet p˚a en g˚ang l¨att blivit sv˚arhanterligt. Det ¨ar d¨arf¨or bra att b¨orja med medelshantering och utv¨arderingsprojektet f¨or att anpassa sig till arbetss¨attet vid implementering av standardsystem. (Rutherhill, 2009) En risk med att bara
ta en liten del i taget ¨ar dock att det ¨ar sv˚arare att engagera hela verksamhe- ten, personalen m˚aste ta f¨or¨andringen p˚a allvar annars kan inget projekt lyckas.
(Eriksson, 2009)
Att byta ett ¨aldre system ¨ar sv˚art oavsett leverant¨or, man m˚aste r¨akna med problem under bytet. Det ¨ar d¨arf¨or bra att Kronofogden har tagit fram M˚alarkitekturen eftersom det inte l¨angre g˚ar att sp˚ara varf¨or det befintliga sy- stemet ser ut som det g¨or, det har byggts ut f¨or m˚anga g˚anger under sin tid.
En f¨ordel med att byta ut hela systemet p˚a en g˚ang hade d˚a varit att man inte beh¨ovt oroa sig f¨or hur anpassningar mellan nya system och det befintliga sy- stemet ska g¨oras innan det ursprungliga systemet ¨ar helt avvecklat. Integration
¨
ar ett omr˚ade d¨ar man antagligen kommer beh¨ova l¨agga mycket kraft f¨or att allt ska g˚a bra. (Rutherhill, 2009)
Testsystem anv¨ands oftast n¨ar det handlar om ett nylanserat system i syfte att s¨akerst¨alla att systemet har den funktionalitet som utlovas, men om det ¨ar ett etablerat system d¨ar det finns tillr¨ackligt med referenser ¨ar ett s˚adant testsy- stem on¨odigt. (Lindberg, 2009) Kronofogdens uppl¨agg med sitt testsystem kan d¨aremot bidra till en trygghet i upphandlingen eftersom man d˚a har kommit s˚a l˚angt att man kan b¨orja f¨ora en dialog med leverant¨oren om vad som ska ske fram¨over men utan att binda sig. Det har ¨aven f¨ordelen att man kan f¨orbereda implementationen av aff¨arssystemet p˚a ett effektivare s¨att. (Eriksson, 2009) Anv¨andningen av testsystemet ¨ar smart men LOU ¨ar fortfarande ett hinder, om utv¨arderingen visar att systemet inte uppfyller deras behov m˚aste Krono- fogden g˚a ut i en ny upphandling d¨ar samma leverant¨or kan utses som vinnare igen. (Eriksson, 2009; Lindberg, 2009)
6 Analys
Analysen syftar till att framh¨ava empirin utifr˚an v˚ar modell och den bakom- liggande teoretiska referensramen. Avsnittet ¨ar strukturerat efter v˚art syf- te och belyser med hj¨alp av modellen Kronofogdens best¨allarkompetens ut- ifr˚an ink¨opsprocessens tv˚a faser samt hur Kronofogden har behandlat sin best¨allarkompetens och vad detta har f˚att f¨or effekt p˚a upphandlingen.
6.1 Kronofogden & aff¨ arssystem
Kronofogden har under flera ˚ar varit medvetna om sitt behov av att byta ut REX mot ett nytt system som kan utvecklas i samma takt som verksamheten.
D˚a de tidigare f¨ors¨oken med egenutveckling inte lyckades b¨orjade Kronofog- den ifr˚agas¨atta egenutveckling som l¨osning p˚a problemet. Den unders¨okning som Kronofogden genomf¨ort resulterade i att aff¨arssystem framstod som en m¨ojlig l¨osning. Att se hur aff¨arssystem fungerade och hur liknande verksamhe- ter anv¨ande dem bidrog till att ¨andra Kronofogdens fokus fr˚an egenutveckling till aff¨arssystem. Genom unders¨okningen byggde Kronofogden upp kompetens om aff¨arssystem och hur ett aff¨arssystem kan passa in i Kronofogdens verksam- het.
F¨or att klarg¨ora hur det nya systemet ska passa in i verksamheten togs den SOA-baserade m˚alarkitekturen fram f¨or att f¨orst˚a hur ett aff¨arssystem ska passa in i Kronofogdens befintligt informationssystem.
Valet av aff¨arssystem bidrog till att upphandlingen blev ett verksamhets- projekt och inte enbart ett uppdrag f¨or VE. Det beror p˚a att b˚ade Kronofog- den och VE st¨alldes inf¨or n˚agot de inte tidigare utsatts f¨or. Ink¨opsfunktionen har best˚att av personal fr˚an alla intresseomr˚aden som systemet ber¨or, vilket har medf¨ort en b¨attre uppfattning om hur standardsystemet och verksamheten p˚averkar varandra. Om Kronofogden l˚atit Capgemini genomf¨ora systembytet hade de tappat denna kontroll och den kompetens det medf¨ort att sj¨alva vara involverade.
F¨or att undvika att binda sig till ett enskilt system valde Kronofogden att anv¨anda en BoB-l¨osning, f¨or att inte beh¨ova byta ut REX alla delssystem p˚a en g˚ang. Att ta ett delsystem i taget bidrar till en trygghet d˚a projektet kan h˚allas p˚a en hanterbar niv˚a men det kommer att ta l¨angre tid eftersom varje delsystem m˚aste integreras med befintliga IT-system. Strategivalet ¨ar ett resultat av erfa- renheter fr˚an studieresorna och tidigare egenutveckling d¨ar Kronofogden insett
problematiken med att byta ut hela systemet p˚a en g˚ang.
F¨or att aff¨arssystemet ska uppfylla Kronofogdens behov m˚aste standard- funktionerna kompletteras med verksamhetsspecifika funktioner. Genom att anv¨anda standardfunktionerna i s˚a h¨og utstr¨ackning som m¨ojligt och endast g¨ora anpassningar i form av till¨agg f¨or specifika funktioner uppn˚ar Kronofogden sitt behov av ett framtidss¨akert system. Detta eftersom anpassningar i stan- dardfunktionerna medf¨or att ¨andringarna m˚aste g¨oras om vid framtida uppgra- deringar.
Utv¨arderingsprojektet av testsystemet har som funktion att l˚ata verksam- heten kontrollera att aff¨arssystemet har den grundl¨aggande funktionalitet som Kronofogden beh¨over. Under projektet ska VE bygga upp den kompetens som kr¨avs f¨or att Kronofogden ska kunna avg¨ora om aff¨arssystemet kan tillfredsst¨alla behovet. Genom att bygga upp egen kompetens f¨or aff¨arssystemet undviker Kro- nofogden att hamna i ett beroende till aff¨arssystemskonsulter, vilket hade blivit ett problem med Capgeminis f¨oreslagna l¨osning. Med egen kompetens kan Kro- nofogdens verksamhet s¨atta sig in i problemen och p˚a s˚a s¨att f˚ar Kronofogden en b¨attre f¨orm˚aga att styra projektet.
Testsystemet f¨orbereder Kronofogden f¨or implementationen genom att verk- samheten f˚ar en b¨attre f¨orst˚aelse f¨or hur aff¨arssystemet passar in i det befintliga informationssystemet. D˚a leverant¨oren i sin tur f˚ar en b¨attre f¨orst˚aelse f¨or verk- samheten b¨or det f˚a som effekt att implementationen av aff¨arssystemet blir l¨attare att strukturera. Denna ¨omsesidigt ¨okade f¨orst˚aelse bidrar till att b˚ada parter f˚ar en b¨attre uppfattning om hur de m¨anskliga aktiviteterna och tekniken samverkar i verksamheten, allts˚a hur det sociotekniska systemet b¨or se ut. Detta inneb¨ar dock inte n¨odv¨andigtvis att implementationen g˚ar b¨attre eftersom det
¨
ar sv˚art att f¨orutse problem som kan uppst˚a vid integrationen med befintliga IT-system.
6.2 Upphandlingen
Eftersom Kronofogden tidigare aldrig upphandlat ett aff¨arssystem fanns ing- en erfarenhet av hur en s˚adan upphandling b¨or genomf¨oras och d˚a det inte finns n˚agon m¨ojlighet inom offentlig upphandling att f¨ora en dialog med le- verant¨orerna fanns en os¨akerhet inf¨or uppgiften. F¨or att kunna framst¨alla ett upphandlingunderlag som preciserade Kronofogdens behov och tydligt visade vad aff¨arssystemet och leverant¨oren skulle uppfylla utgick man fr˚an den kun- skap verksamheten byggde upp genom unders¨okningen av aff¨arssystem.
