Category Archives: Utveckling

Comeback för Nokia 3310?

”Experterna sågar Nokias nya 3310” skriver Omni. Tydligen vill alla ha smartphones nu för tiden, så enligt experterna finns det ingen anledning till att köpa den här telefonen.

Nu är jag ju inte själv expert, så jag är av en annan åsikt. Jag tror nämligen att den här telefonen kan bli en succé. Eller i alla fall framgångsrik.

Så hur får man en galen idé som denna? Att utveckla en nyversion av en telefon som ursprungligen släpptes för nästan 17 år sedan? På mobiltelefonernas tidsskala är 17 år förhistoriskt. Eller för-förhistoriskt. Någonstans mellan Big Bang och ursoppans uppkomst. Någonstans måste man väl ha tänkt fel? Nej. Jag tror att de tänkt helt rätt.

Att surfa med? Den kommer att suga fett. Appar? Glöm det. Sociala medier? Kanske. Att maila? Jodå. SMS och MMS? Det funkar. Ringa med? Givetvis!

Där har vi det. De har listat ut att det faktiskt finns en målgrupp som vill använda telefonen som telefon. Det är egentligen ingenting nytt. Den målgruppen har funnits länge. Men alla mobiltelefontillverkare ser den som förhållandevis liten. Några procent av den totala kundbasen, kanske? Det skulle väl inte löna sig att fokusera på den?

Jodå. Vad man glömmer bort är att även om det handlar om relativt sett liten målgrupp innebär det väldigt många potentiella kunder. Kunder som du inte behöver konkurrera om.

Det är ganska enkelt. Säljer du det alla andra säljer blir det stor konkurrens. Men hittar du någonting som du är ensam om men som efterfrågas av många är du en vinnare. Det är grundläggande konceptutveckling: hitta en målgrupp med behov och önskemål som ingen annan tillgodoser, och bli den som tillgodoser dem. Tänk utanför ramarna.

Ett exempel för att illustrera detta samt problemet med vad experterna tycker är om du bor i en stad om vill öppna ett matställe. Allt som finns i staden är 20 pizzerior. Experterna (eller i det här fallet banken som du vill låna från) kommer att säga att du ska starta stadens 21:a pizzeria, för alla köper ju pizza här i stan. Den som gjort sin hemläxa inom konceptutveckling förstår däremot att behovet av pizza redan är tillgodosett. Att alla köper pizza beror på att det inte finns något annat att välja på. Tittar man dessutom på prisutvecklingen och ser att pizzorna bara blir billigare och billigare ser man att efterfrågan inte bara är tillgodosedd. Den är t o m mättad. Så man öppnar någonting annat. Kanske ett sushihak eller en vegetarisk restaurang. Man hittar sin nisch, helt enkelt. Och det blir givetvis svårt. Banken kommer inte att bevilja lån, eftersom man vill satsa på någonting som ingen rent historiskt sett är intresserad av. Det säljs ju ingen sushi eller vegetarisk mat så då finns det ju ingen efterfrågan.

Kort sagt, jag tror att experterna har fel. Jag tror på nya Nokia 3310: en telefon som man ringer med? Ja varför inte. Det finns många människor som vill använda sin telefon just som telefon och ingenting annat.

One size fits all?

Jag tänkte spinna vidare lite på det jag skrev om dilemmat som uppstår för en organisation när de ställs inför att antingen utveckla egna system eller köpa in färdiga: ”one size fits nobody”. Passar det färdiga systemet perfekt? Är det för stort? För litet? Eller är passformen inte riktigt rätt?

Det här är inte tänkt som något debattinlägg, utan mer ett sätt att illustrera problematiken med färdiga lösningar kontra egna för att göra den tydligare.

Eget eller färdigt?

Slide1.PNG

Ett eget skräddarsytt system som passar perfekt, eller ett färdigt system? Skissen ovan visar ytterligheterna. (Eller worst case scenario, man köper in någonting som inte används utan bygger ett eget…)

Nyckeln i figurerna nedan är överlappet. Det representerar den färdiga funktionaliten out of the box. Det vi får från leverantören. Det vi köper. Den blåa cirkeln är det system som införs i organisationen – det kan vara färdigt och det kan vara egenutvecklat, eller en kombination. Den orange cirkeln är det vi köper. Cirklarna ihop är totalkostnaden.

Exempel 1: perfect fit

Slide2.PNG

Best case scenario. Systemet passar oss perfekt, och utnyttjas fullt ut. Ingen funktionalitet saknas, men inte heller finns det någon överflödig funktionalitet. Det tänker vi oss när vi hör ”färdig lösning”. Det blir dock svårare ju mer specialiserad verksamheten är. Handlar det om standarduppgifter finns det däremot bra exempel. Office-paketet är ett: få använder det fullt ut, men i stort sett allt som ingår används av någon eller några. Och i princip ingen funktionalitet saknas.

Exempel 2: passar väl sisådär…

Slide3.PNG

Det här händer. Troligtvis har man velat köpa in ett färdigt system för någonting det inte finns färdiga lösningar för, och valt något man tror kan fungera om man bygger om och bygger till. Resultatet blir att man lägger mycket tid och resurser på införandet, men när det är klart återstår väldigt lite av det man köpte. Plus att det kanske inte är optimalt för den egna verksamheten. (Se föregående inlägg.)

Exempel 3: enkelt system som byggts ut

Slide4.PNG

Ett bra alternativ om man har egna utvecklare? Man får någonting att bygga ut. Det blir väl anpassat för den egna verksamheten, men bara en del av systemet supportas troligtvis av leverantören. Vill man skala upp får man själv betala för utvecklingen, och risken finns för att man skapar beroenden i organisationen.

Exempel 4: stort system som används till viss del/skalas ned

Slide5.PNG

Ett vanligt scenario? Ett färdigt system som kan mycket, men som ingen utnyttjar fullt ut? Man får mer än man behöver, men behöver inte utveckla eller anpassa det själv. Och det blir lätt att skala upp och införa nya funktioner i framtiden.

Exempel 5: hyfsad passform

Slide6.PNG

När vi köper in större system från större leverantörer hamnar vi kanske här om vi har ett bra underlag med tydliga krav och verksamheten inte är allt för unik. Med stor sannolikhet finns det inget system som har precis det vi efterfrågar och inte heller innehåller sådant som inte behövs. Men i det stora hela är det en bra avvägning där det inte krävs så mycket extra utvecklingsarbete och man inte heller får sådant som inte används.

Det jag tycker är värt att reflektera över när man köper in färdiga lösningar är det här ”överlappet”. Det visar hur mycket av den färdiga lösning man köper in som sedan införs i verksamheten. Det är det man får för pengarna. Därefter kommer egenutvecklingen. Är den väldigt stor i förhållande till överlappet är det inte ett standardsystem man inför, även om det var ett sådant man ursprungligen köpte in.

Om jag skulle rangordna dessa scenarion från bra till mindre bra skulle jag välja den här ordningen:

  • 1: precis rätt för verksamheten.
  • 5: kan med lite jobb anpassas och skräddarsys.
  • 4: har mer än man behöver, men ger någonting att växa i.
  • 3: ett hembygge med färdig lösning som grund.
  • 2: det bidde en tumme.

Nu vill jag dock poängtera att den här rangordningen är utifrån verksamheten jag själv jobbar i. Den är väldigt teknikberoende, specialiserad och har dessutom egna utvecklare (bl a Yours Truly) och drifttekniker. Men uppställningen kan kanske vara intressant när man tittar på system att köpa in?

Bekvämlighetsorienterar du?

Idag läste jag en väldigt intressant artikel i CIO om huruvida man ska utveckla egna system eller köpa in standardlösningar. Är hembyggena skräddarsydda system, eller uppfinner man bara hjulet på nytt? Vad är core business och vad är stödsystem? Eller gäller det omvända ibland? Att man bekvämlighetsorienterar sin verksamhet genom att köpa in färdiga system?

För min egen del är dessa frågor väldigt aktuella just nu. Dels för att jag har jobbat med utveckling inom IT i olika former sedan 90-talet, dels för att vi nu håller på att genomföra en omorganisation på min arbetsplats och dels för att trenden går mot att man outsourcar och köper in färdiga lösningar i allt större omfattning. Standardlösningar är populära.

Det finns dock ett förbehåll: att fler gör samma sak innebär inte att de gör rätt.

Svårigheten ligger i avgränsningarna, vilket tas upp i IDG-artikeln. Den tar dock bara upp en avgränsning, och det är den mellan stöd- och kärnverksamhet och följaktligen vad som är stöd- respektive kärnsystem. För Posten hör logistik till kärnverksamheten, för IKEA är kärnverksamheten inköp och försäljning, och så vidare. Du förstår nog resonemanget.

Men samtidigt finns det fler frågor som behöver svar.

  • Vad är ett standardsystem?
  • Vad innebär ”färdigt” system?
  • Var går gränsen mellan integration/anpassning och utveckling?

Det är enligt min åsikt de här tre frågorna som gör att många satsningar där man köper in färdiga standardsystem inte alltid blir som man har tänkt. För det finns många exempel på det. Läs gärna artikeln i CS om hur det gick för polisen när de skulle gå från halvfabrikatet Pust Java till ”standardsystemet” Pust Siebel. (Tl;dr: åt helvete.) Så låt oss nu titta på de här tre frågorna.

Vad är ett standardsystem?

Det är en intressant fråga. Ställ den till fem olika personer som jobbar med IT i någon form, och det är mycket möjligt att du får fem olika svar. Men om vi ska enas om en vag definition kan vi väl säga att det är ett system som funnits ett tag och har förhållandevis många användare/kunder, och som går att driftsätta nästan out of the box. Windows-familjen är standardsystem. SQL Server är standard. Office-paketet är standard. De har funnits i många år och är beprövade, och man behöver i princip bara öppna en image eller DVD och köra ”Setup.exe”. I teorin i alla fall. I praktiken är det lite mer jobb.

Vad innebär ”färdigt” system?

Där är dilemmat samma som ovan. Svaret beror på vem du frågar. Det är ett system som redan finns och som någon använder. Ungefär som i fråga om vad ett standardsystem är. Grundfilosofin är i alla fall att man inte ska behöva utveckla någonting eget, utan att någon annan redan har gjort arbetet. Allt man behöver göra själv – eller mera troligt hyra in en eller annan konsult (upphöjt i X) att göra – är att driftsätta, integrera och anpassa för den egna verksamheten.

Var går gränsen mellan integration/anpassning och utveckling?

Återigen en fråga utan ett entydigt svar. Det beror på vem du frågar. Vilket i regel leder till att man frågar den som ger det svar man helst vill ha. För det är nu vi kommer till själva stötestenen och det som gör att jag ofta ifrågasätter filosofin med standardsystem och färdiga lösningar: en del av det arbete som görs för att få snurr på dem är utvecklingsarbete (aka ”systemintegration”). Visst, systemet i sig skulle nog fungera om det inte vore för att verksamheten har andra system som det ska fungera med. Ju större verksamhet, desto mer jobb krävs för att få ihop grejerna. Men i ett vakuum fungerar det så klart.

Det var de tre frågorna, och jag har inte sett något tillfredsställande svar på någon av dem. Men varför? Enligt min åsikt för att det ofta är svårt att dra en klar och tydlig gräns mellan stöd- och kärnverksamhet. Det finns alltid en gråzon och i denna olika system och funktioner. Ju lättare verksamheten i sig är att klassa som en ”standardverksamhet”, desto mindre blir visserligen gråzonen. Coop Forum och ICA Maxi är förmodligen väldigt lika varandra. De har samma kärnverksamhet, de har samma behov och därmed kan de troligtvis använda samma system för stödverksamheten. SAS, Finnair och Lufthansa kan förmodligen också använda sig av ungefär samma system eftersom de gör samma sak: frakta resenärer och bagage till samma plats. (Medan KLMs kärnverksamhet verkar vara att via Schiphol skicka resenärer och bagage vidare till vitt skilda destinationer.) Ju fler aktörer som konkurrerar med varandra, desto troligare är det att det finns färdiga lösningar och standardsystem. Men ICA eller COOP kan inte använda samma stödsystem som SAS eller Lufthansa. Visserligen har de alla ”kunder”, men de har helt olika sorters kundrelationer. Standardisera på det viset, och vi kommer behöva boardingkort till mejeridisken på ICA.

I takt med att en verksamhet blir mer specialiserad växer gråzonen mellan stöd- och kärnverksamhet. I synnerhet om de har system som är integrerade med varandra. 

Det beror på att det helt enkelt inte finns system som sedan tidigare är byggda för den verksamhet de ska användas i. Därför gick det åt fanders med Pust Siebel för polisen. Vad polisen behövde var ett system avsett för polisarbete. Men ledningen valde i sin iver att standardisera att införa ett CRM-system (Customer Relationship Management) och försöka anpassa det för polisarbete. Och de missade det mest avgörande – polisarbete är kärnverksamhet inom polisen. Det var alltså inte fråga om ett stödsystem. Men förmodligen var Siebel om inte det bästa så i alla fall ett av de bästa alternativen bland de färdiga lösningar/standardsystem som fanns. Men för polisens arbete finns det inte några standardsystem, eftersom deras verksamhet är unik. Plus att det förmodligen saknades kompetens för att upphandla ett lämpligt system för verksamheten.

Bekvämlighetsorienterar du din verksamhet?

Att göra som polisen gjorde och införa ett system som inte är avsett för ändamålet och sedan försöka anpassa verksamheten efter systemet är ett bra exempel på det jag kallar bekvämlighetsorientering. Med det menar jag raka motsatsen till kundorientering. Att man utgår inte från kundens och kärnverksamhetens behov, utan från den egna IT-organisationens bekvämlighet. Att man försöker anpassa kärnverksamheten efter processerna, som i sin tur anpassas efter systemen vilka anpassats efter stödfunktionernas önskemål, istället för att anpassa stödfunktionerna efter systemen som anpassats efter processerna vilka i sin tur anpassas efter verksamheten. (Därför köper vi gärna onyttig hämtmat till fredagsmyset, eftersom det är bekvämare än att vi ställer oss och lagar någonting eget som vore nyttigare både för plånboken och kroppen.)

Men missförstå mig nu inte. Jag argumenterar absolut inte för att man ska ägna sig åt onödig utveckling där det redan finns fungerande lösningar. Bara en spritt språngande galen CIO skulle gå med på att låta utveckla ett eget ordbehandlingsprogram för att kärnverksamheten är missnöjda med MS Word. Men när systemen når en grad av storlek och komplexitet som innebär att det bara finns en handfull – eller inga – exempel på andra system och verksamheter av samma slag är det inte längre lika uppenbart. Det beror på din verksamhet. Kan du räkna upp flera konkurrenter som det går bra för finns det troligtvis lösningar du kan köpa in och använda. Men vilken verksamhet i Sverige som inte är polisen har med framgång använt Siebel för polisarbete? Den frågan ställdes nog inte.

Dessutom krävs det vass upphandlingskompetens för att köpa in färdiga lösningar. Du kan inte upphandla det du inte själv kan bygga, för då kan du inte heller kravställa det. Så kompetensen för att bygga eget krävs i vilket fall som helst. Kan du inte kravställa det du ska köpa in får du ditt eget Pust Siebel på halsen.