Bakgrund

Systemutveckling har alltid betecknats som ett risktagande, vi vet inte innan vi börjar hur lyckat resultatet ska bli och vi vet inte vad det kommer att kosta eller när det kommer att vara klart. Vi vet inte heller från och med när vi kommer att kunna tjäna pengar på det och oftast inte heller hur mycket pengar vi kommer att tjäna eller förlora.

Naturligtvis är inte ovanstående förutsättningar rimliga i en värld som styrs av väldigt nervösa ekonomiska intressen som helst fokuserar på kortsiktiga vinster.

Det är också därför som man, sedan en lång tid tillbaka, försökt rita om verkligheten så att den blir lite mindre krass för de som vill investera i systemutveckling. Riktlinjen har under många år varit standardlösningar. En standardlösning är typiskt baserad på en ”färdig” applikation som på ett övergripande vis löst de huvudsakliga problem som du förväntas ha inom ett visst omåde (exempelvis inom fakturering). Det enda du ska behöva göra för att anpassa standardlösningen till dina specifika behov är att konfigurera applikationen med ett par begripliga parametrar.

Det är en förförisk tanke och man kan ju förstå att den öppnade dörren till en uppsjö av hel- och halvfabrikat som har sålts för dyra pengar till företag som velat riskminimera deras systemutveckling.

Semantiken

Själva ordet standardlösning behöver nog dissikeras innan vi fortsätter. Den första delen standard är ju en viktig del av ordet – en standard ger liksom en massa goda associationer av något som fungerar överallt och som är tillförlitligt över tid. Dessutom förväntar man sig att det är så eftersom det finns någon form att ickekommersiell instans som utvecklar standarden och som kan godkänna implementationer av standarden, och kanske t.o.m. förse godkända implementationer med något sorts sigill som tydligt kommunicerar till köparen vilken version av standarden som är implementerad. Enligt den engelska versionen av wikipedia förklaras standard såhär :

”Common use of the word standard implies that it is a universally agreed upon set of guidelines for interoperability.”

Tillbaka i standardlösningen måste vi tyvärr konstatera att standard i just standardlösning inte är riktigt lika standard som standard. Istället betyder det här en lösning som, tillverkaren menar att, inte bara du kan använda. Ok, det är ju lite annorlunda, men det finns ju fortfarande en del kvar i ordet och en färdig lösning på ett problem är ju trots allt väldigt bra, även om det inte är en standard.

Har du ett standardföretag?

Här kommer vi in på hur vi använder standardlösningar. Jag nämnde tidigare att du förväntas göra enkla anpassningar av standardlösningen för att den ska fungera i just din organisation. Ofta är det dock inte nog. Som organisation har du ju ett intresse av att representera dina specifika konkurrensfördelar i ditt IT-system och de är ju av hävd inte standardlösningar.

En kollega till mig illustrerade ett sådant problem för bara någon vecka sedan. Han sitter hos en kund (mycket stort svenskt företag med gedigen IT-erfarenhet) där de har använt SAPs CRM lösning vilket är en stor standardlösning för att upprätthålla kundrelationer, i princip kan man säga att det är ett kundregister där man kan upprätta rabatter, köra kampanjer, registrera användarens språkliga preferenser bland mycket annat. Han vittnade om att de hade gjort så många specialanpassningar av standardlösningen att de inte längre kunde uppgradera standardlösningen till de nya versioner som släpps av den. De har dessutom bara ett ytterst begränsat utbyte av den support som de kan få av leverantören (SAP) eftersom de har valt att låta IT-systemet anpassa sig till organisationen… men vänta nu – vad är det för fel i att göra det?

SAP (och många andra leverantörer med dem) hävdar, sensationellt nog, att det är bättre att anpassa organisationen efter deras standardlösningar än tvärtom.

I och med det påståendet tycker jag att de har skjutit sig själva i foten – det klingar väl med att det inte är en standardlösning för alla företag, det är snarare en lösning (utan standard) för en speciell sorts företag som inte har några visioner om att skaffa sig konkurrensfördelar inom de områden där lösningen ska användas.

Unika lösningar

Det finns massor av fungerande standarder i branschen (HTTP, SQL, TCP/IP, JEE), de är kanske inte standardlösningar men de tjänar just de syften som en standard ska och nu när jag presenterar fördelarna med utveckling utan standardlösningar så betänk att de fortfarande vilar på en stabil grund av riktiga standarder som bottenplatta.

Jag har själv varit med i ett par stora projekt där vi utvecklat helt ny programvara och där har den utgjort symbolen för företagets innovationskraft och originalitet. Dessutom är det, i förhållande till den tämligen blygsamma investeringen, en fantastisk dörröppnare hos kunder att säga: ”Vi har en unik lösning som ni inte kan hitta någon annanstans.”

Den tidigare åsikten om att utveckling av specialiserad mjukvara är mer riskfylld än anpassandet av standardlösningar är till stora delar en myt. Projekt med standradlösningar ha visat sig vara dyra, svåra att budgetera, konsultintensiva och ha stora brister i flexibilitet. Dessutom finns problemet att man bygger upp specifik kompetens runt en eller flera proprietära produkter. Sådan kompetens är sällan användbar i andra sammanhang. Idag är vi dessutom mycket bättre på att utveckla unika lösningar av utmärkt kvalitet som levereras på utsatt tid och enligt budget, baserade på riktiga standarder som inte inkräktar på ditt företags integritet.

Så slutligen, tillbaka till det första problemet, hur gör vi med de orimliga riskerna om standardlösningar inte är svaret?

En sådan uppsättning risker som mjukvaruutveckling medför kan inte elimineras, den måste hållas under uppsyn. Det kan vi bara göra genom att upprätta en rak och ärlig kommunikation mellan beställare och leverantör. Beställaren ska regelbundet ges chansen att styra projektet i den riktning som de tror är mest fördelaktig för dem sedan leverantören klart redogjort för vad det lyckats åstadkomma under den senaste utvecklingsperioden. Mellan de kontrollpunkterna ska leverantören ges ro att leverera ett inkrement som är prioriterat av beställaren.

Beställaren måste kontinuerligt hålla koll på deras Return On Investment (ROI), skulle det vara så att man inte kan räkna hem sina investeringar inom rimlig tid så måste man avbryta investeringen direkt så att pengar inte spenderas i onödan.