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.

Annonser

Kommentarer inaktiverade.