Let the Users tell the Story (del 4)

Posted on oktober 22, 2012

2


När jag gick till privata sektorn var det en ganska stor omställning. Det finns inga garantier, utan det är upp till en själv om man kan avancera i företaget och behålla sin anställning. Det mest spännande med att jobba i ett IT bolag som PBS var att man skulle vara specialist inom minst två olika områden och kunna jobba med både offentliga och privata sektorn. En av mina huvudsakliga saker som jag arbetade med var att trendspana så att vi kunde satsa på rätt tekniker och lösningar. Vi måste helt enkelt ha ett försprång till våra kunder.

När jag började så fungerade det så att man hade ett program som man installerade på kundens data och så hjälpte man dem efter bästa förmåga att de skulle få de som de behövde. Efter It kraschen 2001 blev det allt viktigare att man även skulle förstå kundens verksamhet för att kunna leverera bra lösningar (b2b). I och med Sociala mediernas intåg har det blivit allt viktigare att även förstå IT kundens kunders behov. (B2B2C) Business to Business to Consumers.
Det handlar med andra ord om att ge konsumenterna orsaken och möjligheten att berätta sina historier om din produkt.

IT projekt

Några av mina aha upplevelser från IT projekt.

1) I början av 2000-talet så satte man ner mycket tid på vilka kundens behov var att lösa. Det var ofta sådant som det gamla systemet inte klarade av att lösa och sedan satt man även mycket tid på undantag och specialfall. Det som hamnade i skymundan var det som kunden uppfattade som självklarheter och fanns i deras existerande system. Dessa självklarheter nämnde de nästans aldrig till leverantören. De brukade komma in sent i projekten när kunden började att testa lösning och ofta var de av kritisk karaktär, som försenade projekten rejält.Det krävdes med andra ord stor branschkunskap för att kunna ställa rätt frågor åt kunden.

Så man måste som leverantör var skicklig på att få helhetsbilden från alla parter i en organisation. Få användarna att berätta sin story.

2) Jag var på en  IT konferens i Paris i början på 2000-talet. Där fanns det två engelsmän som berättade om vad affärsutveckling var. De var kända från en TV serier där man designade om allt från flygplansstolar, rakhyvel, shoppingvagnar till bh med mera.
De började med att säga att de inte kände till något alls om IT, men deras exempel fick mig att haja till.
De sade att om en tekniker utvecklar en cykel så är den säkert funktionell, men ser som skit, så ingen vill köpa den. Om en designer gör cykeln så ser jätte sexig ut, men är en funktionell katastrof.
Deras poäng var att man måste ha en person som förstår båda världar och har ett stort öra mot användarnas story och erfarenheter.

Detta händer inom väldigt många IT företag, att det är vattentäta skott mellan de olika enheterna och man tolkar samma ord väldigt olika. Många missförstånd har skett genomtiderna tack vare dessa missförstånd.

3) När man sedan skulle få användarna att börja använda lösningen, så måste man kunna säga vad den enskilda individen har för nytta av att göra det, åtminstone som minimum vad företaget eller organisationen har för nytta av det. För om man inte lyckades med det, så var risken att den nya lösningen halta rejält och kanske i bästa fall löste de mest primära problemen.

Det betydde att man måste omvandla Content till Context. Dvs Information som är relevant för varje person.

Business Intelligence

Jag hade förmånen eller den otacksamma uppgiften att komma in i sluten av nästans alla projekt som handlade om ekonomi uppföljning av olika slag. Alla IT system handlar om Input->funktionalitet->output.

Misstagen som skedde var att man ansåg att man inte kunde satsa på output före man hade någon data i lösningen. Det är ju en logisk slutsats, men tyvärr felaktig, för det först när man har intelligent output som snabbt kan se avvikelser, så på ett sätt är det för sent då. Man borde istället fokusera på väldigt mycket vad man vill få ut från systemet och först efter det bygga funktionaliteten.

När det inte stämde i rapporten, så fanns det två alternativ antingen bygg om i funktionaliteten eller göra en manuell fix i rapportprogrammet. Tyvärr blev det oftast alternativ 2 eftersom det borde ha funnits med från första början.

Business inteligence handlar väldigt mycket om att ge relevant information till rätt person. Dvs Context -> Context

Prognos/budgetering

Det är lite fascinerande hur företag jobbar med budgetering. En stor majoritet av företagen använder excel filer för att ”gissa” kostnader och intäkter ett år fram i tiden. Dessutom så använder man excel för att rapportera till sina styrelser.

Jag misstänker att excel har skapat större skada i företag än alla datavirus tillsammans….

I excel brukar man ha olika formler i cellerna, om någon i misstag går och skriver över den, så ser man inte det om man inte går in och tittar på den noggrant. Problemet är då förstås att man tror att det är en formel som ändrar resultat automatiskt, men istället är det ett fast värde. Detta kan helt enkelt vara väldigt svårt att upptäcka innan det är försent.

Jag förstår inte heller hur styrelser kan acceptera excel, som är världen enklaste att manipulera så att man får fram det budskap man vill att läsaren skall få.

CMS (icke information)

Vi var väldigt tidigt ute (1998) med att utveckla ett redigeringsprogram för webbsidor. Jag var inte inbland i början, utan kom med i början på 2000. Omedvetet började jag se textinformation på webbsidor på samma sätt som man gör i business Intelligence. Det formade vår produkt så att man mycket enkelt kunde rikta information till olika besökare.

Runt 2004 fick vi svenska civil försvarsförbundet som kund. Deras utmaning var att de hade 25 000 medlemmar, 330 föreningar fördelat på 30 distrikt. De ville informera samtliga aktörer på ett enkelt sätt via sin publika sida via nyheter(vad som har hänt) och kalendern (vad som skall hända).

I samma veva var det en kollega som berättade om hur piloterna förr i världen väldigt snabbt kunde kolla av instrumenten innan de skulle starta flygturen. Vad de gjorde var att samtliga mätare var kalibrerade att vid normal värde stod visaren 5 över 12. Då såg piloten extremt snabbt vilken mätare som hade avvikande värden.

Vi gjorde en lösning som på första sidan visade en kalender. I den kalendern fanns alla aktiviteter. Klickade man på ett distrikt så fick man utfiltrerat de distriktets och dess medlemsföreningars aktiviteter och klickade man sedan på en medlemsförenings fick man enbart deras. (En s.k. Drill down inom business intelligence världen.)

Det blev trots allt inte den ultimata översikten för man såg inte i första läget direkt om man kunde ha ett möte, så vi gjorde så att om det fanns en aktivitet på en viss dag fick den en gul bakgrund. Detta gjorde att man kunde snabbt se ett datum som ingen i organisationen hade ett möte på. Det gick så långt att general direktören ville att kalender skulle vara helt gul täckt för att visa hur mycket aktiviteter man hade i organisationen. Det blev det ”gula mantrat” och var helt klart inspirerat av cockpit lösningen.

Mig veterligen var Civilförvarets lösning bland de första i världen som handskades med aktiviter och nyheter på detta sätt.