Vitec och utveckling av skräddarsydda IT-system

Finansnovis har redan skrivit om Vitecs bokslutskommuniké och jag tänkte i princip samma sak när jag läste den så jag behöver inte skriva en egen uppdatering på det temat.

Däremot tänkte jag ta tillfället att skriva om varför jag är så intresserad av programvaruföretag som säljer skräddarsydda IT system (analys av Formpipe Software, Vitec, Readsoft och Addnode). De ansvariga för Polisens IT-system JavaPUST har nämligen beskrivit processen med Pust Java och uppföljaren Pust Siebel mycket ingående i Computer Sweden. Hela artikeln är klart läsvärd men jag tänkte citera delar av artikeln för att ge en bild av vad som attraherar mig med nischade programvarubolag.

Användarspecifika system

Användarspecifika system utvecklas i programmeringsspråk såsom C++, C eller Java och för att lösningen ska bli användbar krävs ett nära utvecklingsarbete tillsammans med de tilltänkta användarna. Även om en programmerare är skicklig på att skriva kod är det nämligen osannolikt att utvecklarteamet är specialister på den verksamhet som systemet skall understödja. Det här gäller självfallet även för system baserade på standardlösningar men med användarspecifika system är möjligheterna för kundanpassning större.

Pust var ett ovanligt projekt på polisen på fler sätt. Man såg möjligheten att utveckla både verksamhetsrutiner och systemstöd samtidigt. Utvecklare samarbetade tätt med användare för att förstå deras arbete. Innan något byggdes in i systemet gick man igenom arbetsmetoder tillsammans med poliser. Det här var rätt tillfälle att komma med förbättringsförslag, både stort och smått. Beslutsvägarna var korta. Här handlade det inte om att cementera befintliga rutiner.
Systemutvecklingen gick snabbt, trots allt arbete som lades på verksamhetsförbättringar. Viktigt var att först göra en prototyp, en pilot, till en mindre grupp poliser. De provade i fält, och märkte vad som behövde rättas till.
Redan maj 2011 hade vi infört det nya arbetssättet och utbildat 12 000 poliser i det tillhörande systemstödet i Pust Java. Att det gick så fort berodde inte minst på de agila systemutvecklingsmetoder – lean - som vi fick hjälp av en coach att införa. Kärnan i lean är just att låta användare prova systemet tidigt för att förstå om man är på rätt spår.
Resultatet var enligt rikspolischefen en succé. Användarna var nöjda: En och samma polis kunde nu göra allt klart i ett enda system, med tydlig vägledning steg för steg. Handläggningstiden för vissa mängdbrott minskade med upp till 85 procent.

System baserade på standardlösningar

Men Pust hade använts i endast ett par månader, när det kom ett överraskande beslut. Polisledningen ville stänga det fullt fungerade Pust, som kostat 100 miljoner kronor att bygga och som genererade full nytta.

De flesta andra inblandade såg det som ett befängt beslut. Orsaken var att polisledningen ville genomföra en standardsystemstrategi. Målet var att minska polisens systemflora som sammanlagt orsakade höga kostnader för systemunderhåll. Att stänga ner Pust skulle frigöra resurser till Siebel-utveckling. Att bygga om Pust i Siebel skulle bli dyrt först, men billigare i det långa loppet, menade man.
...

Det var svårt att skrapa ihop Siebelkompetens, men med hjälp av en partner, konsultjätten Accenture, fylldes lokalerna snart av Siebelkonsulter. De arbetade strikt efter sina egna arbetsmodeller. Det tajta arbetssättet med verksamheten upphörde. Man lade även ner den grupp som utbildat alla poliser och hjälpt dem med den viktiga uppgiften att införa nya arbetsrutiner.
En avgörande skillnad mellan Pust Java och det nya Pust Siebel var skillnaden i målbild och samhällsvision. Visionen hade tidigare varit "Skapa möjligheter att få ut poliserna på gatan". I Siebel-projektet var visionen "Spara förvaltningskostnad". Pust Javas direktiv hade varit "Hög användbarhet". Siebel-projektets direktiv var "Bygg samma funktioner som i förra systemet fast nu med Siebel".
Användbarheten ströks tidigt. Det var när vi påpekade att vi ville mäta användbarheten i Pust Siebel. Det gav ledningen kalla fötter. Direktivet ändrades då från ”användbarhet” till ”samma funktioner” och det blev det som gällde. Det är ett tydligt ställningstagande att stryka användbarheten. Det visar att man insåg att det inte gick att uppnå användbarhet.
Siebel är ett standardsystem. Standardsystem består ju av färdiga klossar. Man får ta dessa som de är och bygga ihop dem som det går. Det finns massor av verksamhetsfunktioner som det finns bra standardsystem för, till exempel fakturering, mail, dokumenthantering. Gemensamt för dem är att de ser ungefär likadana ut i de flesta verksamheter.
När man väljer mellan standardsystem och skräddarsytt så är det ett principiellt vägval man gör. Antingen kan man bygga om sin verksamhet så den passar in i ett "färdigt" system – standardsystem – eller så har man en verksamhet som behöver ett specialiserat systemstöd, och då bör man skräddarsy. Mötas på mitten är inget alternativ, för om man gör anpassningar i ett standardsystem förlorar man snabbt möjligheten att använda sig av de generella uppdateringar som kommer från leverantören och som var själva poängen med det hela.

Nackdelarna med skräddarsydda system

Fördelen med de stora standardsystemen är att kundens IT-avdelning för det mesta inte behöver hantera lågnivåkod (alltså C eller Java) och att det finns en stor aktör som garanterar att standardsystemet hela tiden vidareutvecklas och säkerhetsluckor tätas.

Det här är även argument som är lätta att sälja in till chefer på "strategisk" nivå och som vi ser i både exemplet med Pust Siebel och i införandet av PRIO inom Försvarsmakten. I Försvarsmakten insåg man dessutom  tidigt insåg behovet av att anpassa verksamheten efter systemet även om andra fel begåtts i implementeringsarbetet.

I väldigt många fall är argumenten dessutom fullt rimliga. Ett enskilt företag har sällan resurser/intresse av att upprätthålla en intern kompetens för ett unikt IT-system och att leja ut IT-system är därför standard inom många branscher även om Volvo IT har en oerhört intressant lösning på sina behov (som Christer Gardell vill sälja ut).

Nischad programvara, min favoritnisch

Att utveckla programvara är dyrt men för många branscher är de stora systemen så komplicerade och dyra att det finns finansiella incitament för att skapa en skräddarsydd lösning. Att införa ett affärssystem som SAP skulle t.ex. inte vara ett gångbart alternativ för en mäklarbyrå med 6 anställda. Behovet av ekonomiuppföljning är lågt medan behovet av specialmoduler för objekthantering, lagfarter och Hemnet-integration skulle göra systemet dyrt och svårunderhållet trots att det i grunden är en "standardlösning".

Det är i den här typen av begränsade sektorer som jag ser en stor potential för nischade bolag som kan utgå från en skräddarsydd lösning och sedan sälja den som ett standardsystem inom sin nisch. I princip finns det tre krav för att starta den här typen av bolag:

1. En första kund som är villig att driva utvecklingen av ett skräddarsytt system.
2. En begränsad marknad med kunder med samma behov som gör det möjligt att sälja programvaran som ett standardsystem för branschen
3. En säljorganisation som hjälper programmerarna att utveckla funktioner som uppfyller kundernas behov.

Det här är kriterier som jag ser inom många branscher och den stora utmaningen är att hitta de bolag som har tillväxtpotential och effektiv försäljning samtidigt som man ännu ej slagit i taket för sin marknad.