Om att utveckla Produkter i ett Tjänsteperspektiv - Lexicon IT

__________________________________________________________________________________
Om att utveckla Produkter i ett Tjänsteperspektiv
Ett Whitepaper från Lexicon IT-konsult i temat Digital
Transformation
av Lars Wendestam.
Lars arbetar som senior Business Consultant på
Lexicon IT-konsult. Lars har lång erfarenhet av
tjänstetransformering inom IT-branschen. Bland
annat från WM-data och Logica.
Varför behövs tjänstetransformation?
Behovet av tjänstetransformation kan initieras av många olika skäl. Den ökande digitaliseringen i
samhället är ett skäl som uppstår i och med att allt mer sker med inslag av digitala komponenter.
Sakernas internet (IOT – Internet of Things) handlar om hur uppkopplade produkter blir en del i en
större helhet. I vårt behov att ständigt vara uppkopplade förväntar vi oss att vi kan utföra alla typer
av tjänster från olika typer av digital utrustning. Företag som varit vana vid att leverera produkter
mer eller mindre tvingas in till att också kunna leverera tjänster, eftersom dessa uppstår som en
konsekvens i digitaliseringen. Ett exempel är införandet av moln-lösningar som förutsätter att man
också kan hantera en tjänstebaserad leverans. Tjänster och produkter smälter samman. Produkter
omvandlas till tjänster och i ett längre perspektiv till upplevelser.
Trender
Säljer vi produkter eller tjänster är en frågeställning för många företag. Vad man menar med en
tjänst är inte heller helt självklart. Vad som är mer tydligt är de trender som handlar om att förflytta
företagens produktportföljer till att i högre grad innehålla tjänster.
När IBM under 1990-talets första hälft påbörjade resan till att bli ett tjänstesäljande företag var detta
något som blev nödvändigt för att överleva. Då bestod verksamheten av 90 % produktförsäljning och
10 % tjänster. Problemet var att ingen längre köpte deras produkter. Idag är IBM transformerat till
att 90 % av verksamheten utgörs av tjänsteförsäljning medan 10 % utgör av ren produktförsäljning.
Därmed en total transformation till ett omvänt förhållande.
Sanningen är kanske inte så enkel eftersom de levererade tjänsterna innehåller många produkter.
Tjänsteleveransen blir därmed ett sätt att kunna leverera produkterna på ett annat sätt. En sådan
transformering sker i de flesta branscher understödda av ett antal trender.
1
__________________________________________________________________________________
Ovanstående bild beskriv tre trender:



Att vi går från att köpa Produkter till att köpa Upplevelser. Det är hur vi upplever nyttan av
produkterna som är viktigt, inte produkten i sig.
Vi går ifrån att Äga till att Använda. Musikbranschen är kanske det tydligaste exemplet. Vi
köper inte längre CD, men vi förbrukar minst lika mycket musik via streamingtjänster
Den tredje trenden berör att se saker och ting från Utsidan istället för Insidan. Att kunna
betrakta produkterna och tjänsterna utifrån ett externt perspektiv. En undersökning (1) visar
att 80% av företagen tror att man levererar enastående produkter och tjänster, medan bara
8% av kunderna håller med. Detta trots att 95% av de tillfrågade företagens ledning ansåg sig
vara kundfokuserade.
När man ser de tre trenderna gemensamt blir behovet av tjänsteperspektivet uppenbart. Det är
också med denna sanning som det uppstått nya aktörer i många branscher. Se taxitjänsten Uber som
ett utmärkt exempel. Uber har idag över 1 miljard uppkopplade förare i mer än 300 städer. Efter 6 år
omsätter man över 60 miljarder USD. Vad är det då som är annorlunda med Ubers tjänster?
Taxinäringen är mer än 100 år gammal och vad är det som Uber lyckats med så mycket bättre?
Svaret ligger i att man förstått trenderna och gett kunderna en bättre total upplevelse genom att
utnyttja ny teknik och sätta samman detta till en bättre total tjänsteleverans. Uber har fokuserat på
kundens upplevelse utifrån-in i en redan mogen tjänstebransch. Den traditionella branschen
protesterar och hävdar att det Uber gör inte är lagligt. Oberoende av hur man ser på det, berör det
att kunna förstå kunderna i en digital ekonomi. Befintligt sätt att levererar varor och tjänster på
riskerar snabbt att bli föråldrat.
Hur genomför man en tjänstetransformering?
Att transformera Produkter till Tjänster kräver en genomtänkt strategi. Det går inte att genomföra
över en natt. Den stora frågan berör sällan att förstå nya trender i sig, utan att kunna transformera
2
__________________________________________________________________________________
företaget att se sig på ett annat sätt. ”Inside out” är man oftast världsbäst. Vid en ”Outside in”
betraktelse lägger man ofta värderingsnormer i vad man själv tror att kunderna tycker. I en B2B
(Business to Business) relation ligger också slutkunderna ett eller flera steg bort i värdekedjan. Vet vi
egentligen vad våra kunders kunder tycker?
Många försök till att introduceras nya tjänster misslyckas också och dras tillbaka efter en kort period.
Varför kan man undra? Att förstå vad en tjänst är för en verksamhet som är van att tänka i produkter
är inte helt självklart. Här kommer några skillnader:
Produkter
Produceras
Materiellt
Kan oftast beröras
Kan oftast lagras
Leverantören är inte involverad vid användning
Konsumeras efter produktion
Fel identifieras och korrigeras i produktionen
Tjänster
Konsumeras
Immateriellt
Är fysiskt ogripbart
Kan inte lagras
Kontinuerlig interaktion med kunderna
Konsumtion = Produktion
Olika beteenden som uppstår vid användning
Listan kan göras längre men ovanstående punkter är tillräckliga för att påvisa att ett
produktlevererande företag måste göra stora omställningar för att transformeras till att kunna
leverera tjänster. Det berör tjänsternas innehåll men även hur tjänsterna levereras och supporteras
på ett nytt sätt.
Stegen i en tjänstetransformeringsstrategi kan se olika ut. Viktigt är att det ges utrymme för att
”tänka efter” och också att testa sig fram. Alla tjänster kommer inte att bli bra.
Resan börjar i att utforma en ”Service strategi” som ger en grund för att påbörja en transformering.
Med strategin som grund går det att påbörja ett arbete för att transformera produkter till tjänster. I
detta arbete kommer det att uppstå nya affärsmöjligheter som man inte tänkt på tidigare.
Tjänstetransformering – en kreativ process
Att transformera tjänster är en kreativ process som utmanar traditioner med nytänkande. Viktigt är
att förstå den digitalisering som sker i samhället och hur denna påverkar hur lösningar kan utformas
på nya sätt. Förenklat kan man lista följande steg:
1.
2.
3.
4.
5.
6.
Förstå nuläget
Tänka efter för att skapa en strategisk inriktning
Ta fram möjliga koncept för nya tjänster
Filtrerar och prioritera bland identifierade förslag
Skapa en förståelse för utvalda koncept i ett ”Out-side In” tänkande
Realisera konceptet
Att börja arbetet med att förstå nuläget är en grundbult i all typ av förändring. För att veta var du ska
gå måste du veta var du är. Nuläget är utgångspunkten. Med denna som bas gäller det att skapa en
vision för ett framtida läge (To Be) som är målet för transformationen. Själva konceptualiseringen är
3
__________________________________________________________________________________
en kreativ process som behöver förankras i de delar av organisationen som är berörda. I kreativa
processer identifieras både möjliga och omöjliga koncept. Ibland är det omöjliga möjligt, varför det
handlar om att tillåta ”högt till tak”. Att tänka ”lateralt” (på tvärs) är en modell som kan vara
användbar (2).
Av alla idéer gäller det att välja ut några som ska realiseras. Detta kan ske stegvis för att pröva nya
koncept. Viktigt är att hela tiden ha med sig ”Out-side in” tänkandet där man förstår den nya tjänsten
i sitt slutliga sammanhang.
Just behovet av att kunna förstå slutkundens verkliga behov är en utmaning i tjänstetransformering.
Det är lätt att i första hand bygga tjänsteleveransen utifrån det egna produktionsperspektivet. Hur vi
som företag idag har satt samman våra leveranser istället för att se det fullt ut ifrån ett
kundperspektiv.
Klassiskt problem vid Outsourcing
Att etablera ett tjänsteförhållande genom att ”outsourca” delar av verksamheten till en extern
leverantör blev under 1990-talet en trend för IT-branschen. Man köper tillbaka IT, men nu via en
extern part som återlevererar som tjänster. Det kunde kanske då ses som en genväg för att få på
plats en tjänsteleverans. Detta medförde att branschen stegvis tvingades bygga upp bättre och
bättre ramverk för hur man levererar tjänster. IT-service Management ramverket ITIL (3) (IT
Infrastructure Library) lanserades 1999 i en ny version och blev därefter en ledstjärna för många
inom Service Management. ITIL innehåller mycket av det som krävs för att få en fungerande
tjänsteleverans på plats och inte bara för IT-företag. Det finns många exempel på Tjänster som inte
är IT-relaterade, där ITIL använts som grund för uppbyggnad av Service Management processer.
Ett problem som IT-branschen hela tiden lidit av är att kunna förstå behovet ”Out-side in” fullt ut.
Forskare vid University of Tennessee har studerat detta och funnit just problem i kund –
leverantörsförhållandet avseende att förstå vad tjänsterna borde vara. Man konstaterar att
merparten av outsourcingtjänster är ”Transaktionsorienterade”, vilket innebär att leverantören får
betalt baserat på hur mycket man utför. Detta har skapat låsningar när det gäller att tänka nytt
utifall man i en rationalisering behöver mindre av tjänsten. Då saknas incitamentet för att förändra
tjänsten hos leverantören. Alla parter ställer sig frågan ”What is in it for Me”. Det koncept som
University of Tennesse tagit fram kallas för Vested (4). (Ordet Vested betyder beständigt.) Att skapa
en beständig relation med kunderna och istället tänka ”What is in it for We”. Hur kan vi i ett
partnerskap tillsammans skapa ett högre mervärde.
I ett sådant tankesätt är tjänsterna inte längre transaktionsorienterade. Det handlar då inte om hur
mycket lagringskapacitet eller datorkraft man tillhandahåller. Tjänsterna skall vara, vad man kallar för
”Outcome”- baserade. Med det avses att betrakta dem fullständigt ”Outside-in” från
kundperspektivet. Vad är det egentligen som kunden behöver och hur kan leverantören vara delaktig
i att åstadkomma detta.
Kundbehovet är sällan transaktionsorienterat utan det finns något annat bakomliggande behov som
är mycket större. Ett exempel som ibland används i sammanhanget är ett flygbolags olika tjänster
som behövs på en flygplats när flygplanet har landat. Planet behöver tankas och städas. Bagaget skall
tas om hand. Passagerare skall av och nya skall på. Ny mat skall ombord och planet skall vändas så
4
__________________________________________________________________________________
det kan påbörja en ny destination. Desto kortare tid flygplanet står vid gaten desto bättre. Alla dessa
tjänster levereras av olika tjänsteleverantörer som transaktionsorienterade tjänster. Bagagehanteringen får betalt per hanterat bagage o.s.v. Om vi tänker efter är detta inte det som är det
bakomliggande behovet från flygbolaget som köper tjänsterna. En ”Outome”-orienterad tjänst skulle
i stället kunna formuleras som ”Vänd planet på 20 minuter”. Hur detta görs och effektiviseras ligger i
leverantörens åtagande. Kunden söker en ”Outcome” och tillåter leverantören att självständigt
rationalisera hur detta sker praktiskt. De tidigare transaktionsorienterade tjänsterna blir underställda
det ”Outcome” baserade behovet.
Vested-modellen är intressant inte bara ur ett outsourcing perspektiv. Den tvingar fram ett behov att
kunna förstå kundernas verkliga bakomliggande behov. I många branscher vet man inte hur de
produkter man säljer används. I en värdekedja förädlas dessa också i många fall l flera steg.
Produkter ingår i tjänster som förädlas till nya tjänster.
Digitaliseringens effekter och ”the API-economy”
I den digitalisering som sker i samhället är oförståelsen av slutkundsbehovet ett problem. Det
tidigare exemplet med Uber är slående. Med hjälp av ny teknik går det att hitta nya genvägar i
etablerade värdekedjor och konkurrera ut befintliga aktörer. Att förstå digitaliseringens påverkan på
egna värdekedjor är därför mycket viktigt vid en tjänstetransformering.
Vad Uber och flera nya aktörer kunnat utnyttja är någon som brukar kallas för ”the API-economy”.
Fritt översatt ”gränssnittsekonomin”. API betyder ”Application Program Interface” och avser ett
standardiserat gränssnitt som finns mot olika typer av programvaror. Uber har i sin tjänst paketerat
samman olika API:er mot kartsystem, positioneringssystem, betalningar m.m. som tillsammans
skapar en bättre upplevelse för kunderna. Genom att använda standardiserade API:er kan man
tillhandahålla tjänsterna med bra säkerhet och betydligt kostnadseffektivare både för slutkunden och
föraren. API-Management är således en viktig komponent i en nya Tjänstearkitektur.
Att etablera en Tjänstearkitektur
Med arkitektur menar vi de grundläggande koncept och lösningar som krävs för att etablera en
slutprodukt. Är slutprodukten en tjänst, behövs därmed en Tjänstearkitektur. Följdfrågan blir direkt –
”Vad innehåller en tjänstearkitektur?”
I engelsk terminologi pratar man om behovet av en ”Enterprise Architecture” förkortat ”EA”. Hur
denna utformas är givetvis beroende av vad man är för slags verksamhet. I en egen genomförd
inventering har identifierats ett 50-tal olika EA-ramverk. Många är branschspecifika och tagits fram
för att lösa den specifika branschens problemställningar. I en transformering till en tjänst behöver
också arkitekturramverket vara öppet för utformning av tjänster. Flertalet av EA-ramverken är ej
heller upplåsta till att stödja specifikt produkter eller tjänster. Istället gäller det att tillföra
komponenter som stödjer tjänstetänkandet. Idag är merparten av dessa vad man kallar för
molnbaserade (Cloud Computing). De tillhandahålls över ett öppet nät. Grundstrukturen bakom
behöver stöda de tekniska lösningar som krävs för att utnyttja moln-tjänster som AWS (Amazon Web
Services), Microsoft Azure med flera.
5
__________________________________________________________________________________
Ett EA-ramverk brukar indelas i skikt som täcker minst följande tre delar:



Business Architecture
Application & Data Architecture
Technical Architecture
Till dessa kan tillkomma separerade delar som t.ex. berör säkerhetsfrågan (Security Architecture). En
sådan berör då alla tre skikten. I en transformation för att förflytta en verksamhets produkter till
tjänster, eller att förädla dess tjänster till upplevelser, behöver man parallellt definiera
arkitekturramverket som skall understöda de nya tjänsterna. Man utgår då på samma sätt från ett
Nu-läge (Baseline Architecture) och definierar en ny målarkitektur (Target Architecture).
En arkitekturtransformering sker med fördel ”Outside-in”. Utgångspunkten är den Affärsarkitektur
(Business Architecture) som krävs för att kunna leverera Tjänster till kunderna. För att förstå vad
tjänsterna skall innehålla behöver man förstå sina egna kunders kunder, eller rent av kunder som
ligger tre steg bort i en B2B-värdekedja. Affärsarkitekturen utgör sedan grunden för att etablera en
”Application & Data Architecture”. I denna beskrivs de system och lösningar som behövs för att
understödja affärsarkitekturen. En viktig komponent i dataarkitekturen är att kunna utnyttja och
använda öppna gränssnitt (API:er). Både att kunna använda externa API:er för att öka värdet i egna
tjänster, samt att kunna tillhandahålla egna API:er på egen data som utgör komponenter i kundernas
tjänsteförädling. Sista delen berör en infrastrukturell och teknisk infrastruktur (Technical
Architecture) som beskriver de infrastrukturella komponenterna oftast inkluderande ett flertal
molnbaserade tjänstekomponenter. Det kan ibland vara frestande att börja med molnfrågan då man
ganska snabbt kan komma i dialog med moln-leverantörer som tillhandahåller många intressanta
tjänster tekniskt. Risken med att bygga det ”Inside-Out” är att man definierar en teknisk arkitektur
som i slutändan inte kan understödja en ny affärsarkitektur.
Ett EA-ramverk som tillhandahåller en transformationsmodell är TOGAF (5). Själva
transformationsmodellen kallas TOGAF ADM (Architecure Development Method). Ovanstående steg
som beskriver hur man förflyttar sig från en nulägesarkitektur till en målarkitektur är hämtade från
TOGAFS ADM modell.
En kritik man kan ha gentemot de flesta EA-ramverken är att de inte är tillväxtorienterade. På vilket
sätt en verksamhet vill växa. Ett företag som växer med hjälp av en förvärvsstrategi har ett annat
behov av EA än ett företag som växer organiskt. Det borde kanske snarare vara dessa dimensioner
som särskiljer ramverken snarare än branschtillhörighet.
De nya tjänsternas belastning på befintlig organisation
I ett transformeringsarbete som etablerar tjänster som komplement eller ersättning för produkter
behöver det även ingå funderingar över hur organisationsutformning stöder de nya
leveransformerna. Man levererar inte tjänster på samma sätt som man levererar produkter, som
sammanställningen ovan beskrev. Skillnaderna kan i många fall tyckas vara självklara, men dess
påverkan på den levererande organisationen är inte lika självklar. En leverans som kräver kontinuerlig
interaktion med kunderna behöver också en organisation som är uppbyggd för att understödja detta.
Var finns dessa resurser? I en produktionsorganisation kan oftast inte resurser frigöras omedelbart
för att ta hand om kundproblem. Detta är mer eller mindre nödvändigt i en tjänsteleverans.
6
__________________________________________________________________________________
När man levererar tjänster eller produkter som inkorporerar tjänst behöver en supporterande
tjänsteorganisation etablerat t.ex. enligt ITIL eller något motsvarande ramverk. Ett kompletterande
arbete med organisationsutformningen måste ske under själva tjänstetransformeringen.
Samverkande modeller
Som framgår av denna artikel är att tjänstetransformeringen behöver stödjande metodik. Här
handlar det om att kunna kombinera tankesätt från flera olika metodramverk. Vi har här berört
behovet av:






En kreativ tjänsteutvecklingsprocess
En Service management modell som t.ex. ITIL
En Samverkansmodell som t.ex. Vested Methodology
Ett EA-ramverk som understödjer en ny ”Business Architecture”
En struktur i EA-ramverket för att inkorporera API-Management i ”Application Architecure”
En teknisk arkitektur som baseras på molnbaserade tjänster
Dessa ramverk och metoder samverkar vid en tjänstetransformering. Inom respektive områden kan
det också kompletteras med andra ramverk. ITIL är inte speciellt omfattande gällande hur man
utformat ett Service Center. Här kan man då komplettera med andra ramverk som tex COPC (6). På
samma sätt finns andra modeller som är bättre vid utformning av Tjänstekataloger och
Tjänstestrukturer. I grunden gäller det att kunna etablera ett förändringsprogram som understöds av
rätt arbetssätt och metodstöd.
Om Lexicon IT-konsult
Lexicon IT-konsults framgång bygger på riktigt nöjda kunder och engagerande medarbetare. Vi
levererar det stora företagets IT-kompetens med den enskilde konsultens engagemang.
Vi hjälper våra kunder och stärker deras konkurrenskraft genom att tillföra generell samt strategisk
IT-kompetens, åtaganden och lösningar med engagerade konsulter.
Våra kunder är i första hand organisationer och företag som har behov av konsulter och lösningar
inom olika erbjudandeområden och söker en snabb, kvalitativ och engagerad leverantör. Genom att
kombinera teknisk spetskompetens inom områdena Infrastruktur, Applikation och Business
Consulting och kunskap om våra kunders verksamhet tillför vi en helhetssyn inom IT-området.
Lexicon IT-konsult startade 2007 och finns idag med egna kontor i Stockholm, Göteborg, Malmö.
Lexicon IT-konsult arbetar inom området som berör del förändring som krävs både organisatoriskt
och verksamhetsmässigt för att möta den ökande digitaliseringen i samhället. Detta är en
kontinuerlig process som vi valt att dela upp i:
 Digital Transformering
 Digital Optimering
 Digital Operation
Inom området Digital Transformering ingår analyser och genomförande av utredningar för att göra
förändringar i verksamheter för att möta det ökande behovet av digitalisering. Det handlar om att
7
__________________________________________________________________________________
organisera och etablera verksamhetsfunktioner för att understödja tjänster i så väl offentliga
verksamheter som privata företag. Med Digital Optimering avses förbättringar i nuvarande tjänster
som krävs för att kunna uppnå de effekter som efterfrågas i en digital transformering. Det berör
utveckling och stöd inom internetbaserade tjänster som Web-services, API-Management, IoT
(Internet of Things), BYOD (Bring Your Own Device) med flera. I Digital Operation ingår att kunna
etablera tjänster som i allt högre grad sker i ”molnet” genom att utnyttja ”cloud-tjänster” från
leverantörers som AWS (Amazon Web Sevices), Microsoft Azure med flera. För att möta alla
utmaningar som finns i den pågående digitaliseringen krävs ett kontinuerligt arbete med att
transformera, optimera och etablera nya tjänster med ny eller gammal infrastruktur.
För mer information, se http://lexiconitkonsult.se/
Noter
1.
2.
3.
4.
5.
6.
Undersökning genomförd av Bain % Company, där man tillfrågade 362 företag. Man kallar detta för ett ”delivery gap”
Edward de Bono om Lateralt tänkande: http://www.debonothinkingsystems.com/tools/lateral.htm
IT Infrastructure Library (ITIL) version 3. https://www.axelos.com/best-practice-solutions/itil
Vested Outsourcing Methodology från Uinversity of Tennesse. http://www.vestedway.com/
Open Group - TOGAF version 1.9. https://www.opengroup.org/togaf/
COPC (Customer Operations Performance Centre). http://www.copc.com/
8