Konsulting och bemanning blandas lätt ihop i IT-branschen. Om kunder och leverantörer börjar tala klarspråk om vad de efterfrågar och erbjuder så blir resultatet en mycket effektivare marknad.

Skillnaden mellan konsulting och bemanning börjar och slutar i kundens synsätt på tjänsten som köpts. Du anlitar en konsult för att du har ett problem och behöver hjälp att lösa det. Du ska inte behöva veta hur uppgiften ska lösas, bara att det behöver göras.

Anlitar du ett bemanningsföretag däremot vet du precis vad som behöver göras, men du saknar någon som kan göra det. Även om arbetet som ska utföras kan vara komplext och kräva djup kompetens så är utgångsläget helt annorlunda.

När du som kund har en väl avgränsad uppgift som måste utföras så handlar valet av leverantör bara om den klassiska frågan: billigt, snabbt och bra; välj två. För leverantören så blir det en förutsägbar affär: hög beläggningsgrad, men marginaler som i bästa fall kan kallas goda för de som kan positionera sig i premiumsegmentet.

Men när du som kund står inför ett problem, för dig känt eller okänt, så fungerar inte marknaden på samma sätt. Andra prismodeller blir möjliga, och som leverantör kan du på ett helt annat sätt få rejäla marginaler. För områden där möjligheten att mäta ROI är god begränsas intäkterna inte av något annat än hur mycket värde du kan skapa för din kund. Där det inte är lika lätt att mäta direkta effekter av en konsultinsats så kan man i alla fall få mycket bra betalt för nedlagd tid.

Bemanning innebär att du som leverantör förväntas leverera ett antal persontimmar där personen ifråga presterar ett godkänt resultat. Som leverantör vill du ha så många uppdrag som möjligt eftersom lönsamheten per debiterad timme är relativt låg och kompetensen behöver bara matcha kundens kravprofil. Som kund vill du hålla kostnaden nere sålänge som “jobbet blir gjort”.

Konsulting innebär att du som leverantör vill skapa så mycket värde som möjligt för din kund, eftersom ditt resultat direkt eller indirekt är kopplat till kundens. Som kund ställer du bara konsultens ersättning i relation till skapat värde och att byta leverantör görs inte för en smärre kostnadsbesparing. Du som leverantör vill inte växa för storlekens skull utan expanderar bara när tiden är rätt och kompetensen säkrad.

Det finns inget fel i att syssla med vare sig bemanning eller konsulting. Men det gäller att vara tydlig med vilket av dem som gäller – både som kund och leverantör. Jag tror att många misslyckade IT-projekt kan härledas till en situation där kunden förväntade sig en konsult men leverantören inte hade kompetens till detta. På samma sätt kan de flesta konsulter vittna om frustrationen som uppstår när kunden förväntade sig inhyrd personal men skaffade konsult.

Till att börja med: att kunder ska betala för samtal som har ringts är självklart. Enligt lag kan privatpersoner faktureras upp till 36 månader efter att tjänsten levererats, men också moraliskt tror jag inte många tycker att Tele2 inte ska få betalt för de här samtalen även om de inte blivit fakturerade innan.

Men man bör ha förståelse för att alla kunder, och speciellt privatpersoner, kan ha svårt att hantera en stor skillnad i fakturerat belopp mot det förväntade beloppet. När det högre fakturabeloppet beror på en ren miss från operatörens sida och inte något som den enskilda kunden kunnat påverka, då gäller det att vara än mer flexibel och tillmötesgående som företag om man värderar sin kundrelation. Tele2 har ju uppenbarligen inte haft ett särskilt stort kassaflödesproblem för att de saknat den här intäkten i ett år, medan 22% av Sveriges hushåll inte kan klara en oförutsedd utgift på 5000 kr. Alltså: samtalen ska betalas, men det kanske inte är nödvändigt för Tele2 att få in hela beloppet på en gång.

Det är lätt att sitta på utsidan och raljera över hur dåligt skött en situation är, när man helt saknar insikt i hur det ser på insidan. Därför tänker jag istället kort beskriva hur jag tycker att man från Tele2s sida hade kunnat göra för att ytterst få personer skulle kunna ha några invändningar på hur man agerat.

Det finns ett antal problem som skapas när man behöver göra en sådan här efterdebitering. Några av dom är:

1. Privatkunder har svårt att hantera en oväntat stor faktura en månad. Studenter är överrepresenterade bland Tele2s kundstock och har extra svårt med oplanerade utgifter, speciellt inför sommaren.
2. När ett större antal kunder får en sådan här faktura så ökar belastningen på kundtjänst mycket över en natt. Längre svarstider och mer stressad personal leder i sin tur till en högre frustration bland kunderna som försöker reda ut en situation där de redan har en negativ grundinställning.
3. Frustrerade och irriterade kunder kommer att ställa kompensationskrav som påverkar lönsamheten.

För att lösa punkt 1 så hade jag sett till att man kan på ett relativt enkelt sätt välja mellan att fakturera hela beloppet på en faktura eller att dela upp efterkravet på de kommande 6 fakturorna. Eventuell ränta bör man ta på goodwillkontot.

För att lösa punkt 2 så hade jag sett till att det fanns ett skalbart sätt att låta kunder välja hur de vill betala efterkravet. Helst hade det funnits på plats innan någon annan information till kund skickades ut, men man kan skapa ett sådant nu också och informera genom kundtjänsts IVR. Det behöver inte vara något krångligare än ett formulär skapat med exempelvis Wufoo som samlar in kundnummer, fakturanummer och valt betalningssätt (hela beloppet, 3 månader, 6 månader exv). Total kostnad: 1 timmes arbetstid och några dollar till Wufoo. Extra credit: översättning av formulär och information till fler språk än svenska.

Genom att styra över så många kunder som möjligt till att använda formuläret hade belastningen på kundtjänst minskat, vilket minskar frustrationen hos kunderna. De allra flesta kunder vill betala för samtal de ringt, men kan inte göra det på en gång och skulle då uppskatta att få extrakostnaden uppdelad. 100 kr extra i månaden i 6 månader istället för 600 kr på en månad gör mycket stor skillnad för en students ekonomi.

Insamlad data får man ut från Wufoo i ett vanligt Excelark. Sen gäller det att processa den informationen och göra de ändringar i faktureringssystemet som krävs för att kundernas val ska bli verklighet – säkert ett stort jobb, men ett jobb som borde kunna automatiseras och i varje fall kan göras utan att ha en upprörd kund i andra änden av telefonluren medan det utförs.

Det här är såklart ett naivt exempel och jag har säkert missat många detaljer. Men det är en stor skillnad för kunden på att få ett brev med fakturan där det står “Din faktura är 500 kr högre än vanligt på grund av ett fel på vår sida. Betalning ska vara oss tillhanda om 30 dagar” eller “Tyvärr har en miss hos oss inneburit att inte alla samtal du ringt blivit fakturerade. Totalt är kostnaden på 500 kr, och om du vill kan vi dela upp den kostnaden på X antal månader. Var snäll och gå till tele2.se/efterdebitering för att välja hur du vill betala de här samtalen.”

Att man inte gör något sådant här utan istället låter kunderna och kundtjänst ta smällen visar på att man behöver ge de som jobbar med kundvård större mandat till egna iniativ och de verktyg som behövs för att hitta på kreativa lösningar på den här typen av situationer.

Tydligen så läker sår mycket fortare och bättre om man applicerar en sugkraft på dom (ursäkta den troligtvis felaktiga terminologin). Fördelarna är bland annat att man kan lämna ett förband på i flera dagar istället för att behöva lägga om det tre gånger om dagen vilket behövs vid traditionella förband med öppna sår. Det har varit känt relativt länge men utnyttjas inte så ofta eftersom kostnaden för maskiner som kan hålla igång den här sugkraften varit så pass hög.

Bilden ovan visar MIT-doktoranden Danielle Zurovciks lösning på detta problem, som egentligen bara är ett lufttätt förband, en slang och en handdriven luftpump (typ likadan som används för luftmadrasser, fast omvänd sugkraft). Total tillverkningskostnad $3, jämfört med de maskiner som använts tidigare som kostat upp emot $100 per timme.

Det nya förbandet och pumpen testades först på Haiti, och är snart klar för serietillverkning enligt Fast Company. Helt fantastiskt.

Som framgår av mina tidigare inlägg här så registrerade jag den här domänen och började blogga för att kunna slå alla andra Martin Melin i Googles sökresultat för vårt namn.

Därför vill jag gärna hjälpa andra med liknande projekt, och det här är något som jag tycker är en rolig idé som görs för en viktig sak. Med bilden här nedanför bidrar jag med den lilla länkkraft jag har till att nyansera sökresultaten i Google för ett av 2010 års viktigaste sökord:

När Amazon släppte tjänsten EC2, Elastic Compute Cloud, så var det väldigt nytt att kunna starta och stoppa maskiner på timbasis, och bara betala för användningen (24 timmar = en maskin i ett dygn, eller 24 maskiner i en timme – samma kostnad).

Idag har många, många fler hoppat på det tåget och imiterat EC2 på mer eller mindre lyckade sätt. Nu försöker till och med vanliga svenska webbhotell följa efter, genom att köpa en “Cloud Computing Platform”-tjänst som Enomaly.

Men Amazon släppte EC2 redan 2006, och har sedan dess fortsatt att skapa nya innovativa tjänster som Simple Queue Service, SimpleDB, Elastic Block Store, etc. Allt för att göra det enklare att bygga applikationer helt i Amazons moln.

Nu har de tagit nästa steg, något som är fungerar för någon med Amazons skala men som blir svårt att kopiera för små webbhotell med köpelösningar: Spot Pricing.

I princip är detta auktionssystemet som gjorde Google AdSense så framgångsrikt, applicerat på instanser i Amazons moln. Alla som har ett EC2-konto kan registrera 1) hur många instanser de vill starta och 2) hur mycket de maximalt vill betala för instanserna. Amazon bestämmer utifrån den här informationen ett marknadspris för en instanstimme, och alla vars angivna maxpris ligger över marknadspriset får sina instanser startade.

För att inte kannibalisera på vanliga EC2-instanser (som hyrs för ett fast timpris) och för att möjliggöra snabb anpassning till marknadspriset, så kan en “Spot Instance” stoppas när som helst. När marknadspriset för en instanstimme går över vad du betalar för din “Spot Instance” så stänger Amazon av din instans direkt, utan att vänta till nästa timme.

Det här är självklart ingenting som man kan eller bör använda för att köra en webbserver eller något annat som har krav på tillgänglighet och upptid. Det öppnar snarare möjligheter för en helt annan typ och klass av applikationer att köras så kostnadseffektivt som möjligt. Om du har ett stort konverteringsprojekt, eller en strid ström av tidskrävande operationer som inte nödvändigtvis har en fast deadline, så kan du nu registrera en stående order med Amazon att du vill köpa X antal instanser, att köras så länge priset understiger Y dollar.

Det här är alldeles genialt: Amazon får ett sätt att nå mycket nära 100% kapacitetsutnyttjande hela tiden, och köpare får ett nytt sätt att hålla sina kostnader nere för icke-tidskänsliga applikationer. I tanken liknande “off-peak” och “on-peak”-priser för exv. bandbredd eller elektricitet, men självklart mer komplext.

“If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place” – Eric Schmidt, Google

Eric Schmidt visar på en mycket oroväckande inställning till integritet, och det finns få positioner där en sådan åsikt kan göra mer skada än som Googles CEO.

Apropå det uttalandet påmindes jag om Bruce Schneiers välskrivna The Eternal Value of Privacy från 2006:

For if we are observed in all matters, we are constantly under threat of correction, judgment, criticism, even plagiarism of our own uniqueness. We become children, fettered under watchful eyes, constantly fearful that — either now or in the uncertain future — patterns we leave behind will be brought back to implicate us, by whatever authority has now become focused upon our once-private and innocent acts. We lose our individuality, because everything we do is observable and recordable.

Människors beteende förändras när de är medvetna om att de kan vara övervakade. Oavsett hur otroligt det är att någon skulle vara intresserad av just deras kommunikation, så finns kunskapen om att möjligheten finns undermedvetet kvar. De flesta kanske inte ens märker effekten, men faktum kvarstår: det uppstår en självsanering, en egencensur, av människors kommunikation genom att berätta att de kan vara övervakade.

Vi vet inte vad effekten av det här blir om 10 år, 20 år, 100 år. Och det farliga är att vi aldrig kommer att objektivt kunna bedöma hur vårt beteende har förändrats, eftersom förändringen sker så gradvis att vi inte ser skillnaden.

I datorsammanhang pratar man ofta om Mean Time Between Failure, MTBF. På enskild komponentnivå är det såklart väldigt intressant att veta MTBF för att veta förväntad livslängd på komponenten ifråga.

Men när man tittar på tjänstenivå så kanske det är mer intressant med Mean Time To Recovery, MTTR. Hur lång tid tar det för tjänsten att återställas till normal drift när väl ett problem inträffar? Kombinerat med ett SLA ger MTTR en klarare bild av vilken typ av nedtid man kan förvänta sig från en tjänst man är beroende av.

Ett SLA-åtagande på upptid på 99.9% på årsbasis säger egentligen inte mycket. Det ger utrymme för nästan 9 timmars nedtid på ett år, men man vet ingenting om hur tiden är uppdelad. Är det ett 10-minutersstopp i veckan, eller ett enda stort avbrott på en hel arbetsdag? Beroende på tjänsten kan man föredra olika modeller, men poängen är att man inte vet hur det ser ut.

Om man däremot också fick se en siffra på MTTR så får man en mycket tydligare bild av det genomsnittliga avbrottet.

Problemen med att planera för framtiden efter historiska resultat utelämnar jag passande nog från detta inlägg.

Jag märkte då något mycket intressant på tvåårsgrafen över trafiknivåerna:

Det stora fallet i våras är ju den omtalade “IPRED-effekten”. Men titta vad som har hänt efter en sommar utan några fällande domar; trafiken är tillbaka på den nivå den var innan IPRED trädde i kraft!

Undrar vad som händer nu när det första och mest uppmärksammade IPRED-fallet har stängts ner av hovrätten som klokt nog förstått att material inte är “tillgängligt för allmänheten” bara för att det finns tillgängligt på en lösenordsskyddad server.

När du tillverkar en stor tårta så kan du börja med en tårtbotten, lägga på lager efter lager av fyllning och avsluta med glasyr. Men du kan också börja med en liten muffins, för att sedan gradvis baka större och större bakverk. Fördelen är att du alltid har något att servera, även om du får slut på tid eller pengar halvvägs in i projektet.

Eller det lite mer seriösa citatet som Contrast länkar till:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” – John Gall, Systemantics

Ted Valentin arrangerar tillsammans med Stockholm School of Entrepreneurship, en organisation jag inte känner till särskilt väl mer än att de brukar bjuda in till diverse events med koppling till entreprenörsskap. Det återstår att se om det blir samma känsla som i januari, speciellt när anmälningssidan begärde “en ansökan på max 2 A4″ vilket kändes väldigt lite 24hbc. Kul blir det nog oavsett!