Flere og flere selskaper bruker sosiale medier for å kommunisere med kundene sine. De siste årene har sosial CRM utviklet seg til å bli en av de viktigste temaene for alle som arbeider med kundestrategi og kundeopplevelse. De fleste undersøkelser underbygger nettopp dette; Kunder (både B2B og B2C) bruker sosiale medier for å kartlegge, diskutere og søke anbefalinger i forbindelse med kjøp av en vare eller tjeneste. Likevel viser flere undersøkelser at så lite som kun 7% av selskaper forstår verdien av å linke sosiale medier og CRM strategi. På tide å våkne opp!

Hva handler ”sosial” egentlig om?

Det å sosialisere kundestrategien handler først og fremst om å anerkjenne at vi må jobbe med kunderelasjonen på kundens premisser og at selskapets jobb først og fremst er å fortjene en tillitt hos kunden som igjen kan brukes til markedsføring, salg og kundeservice. Det handler om at kunder forventer å bli behandlet som individer med ønsker og behov, snarere enn et kundenummer i en kundedatabase.

La meg gi deg noen eksempler på hvordan en sosiale kundestrategi er annerledes:

Hvem?  I din tradisjonelle kundestrategi har du ofte definert avdelinger eller enkeltpersoner ansvarlig for CRM. I en sosial kundestrategi endres dette – der alle ansatte vil være del av strategien, gjennom sosiale kanaler og andre møtepunkter med kunden.

Hva? Markeds- og kundeserviceavdelingen har trolig vel definerte prosesser for hvordan kundekommunikasjon og oppfølging er definert gjennom en kundes livssyklus. In en sosial CRM-strategi definerer kunden disse prosessene og du kan ikke lenger støtte deg på predefinerte kommunikasjonsplaner for å følge opp kunden.

Når? Du kan ikke lenger definere når du skal være tilgjengelig for kunden. Sosiale kunder kommer til å kommunisere med deg når de selv ønsker og lar seg ikke begrense av definerte åpningstider på kundeservice eller i salgsavdelingen.

Hvor og hvordan? I den tradisjonelle CRM strategien har du antakeligvis definerte kommunikasjonskanaler satt opp, eksempelvis nyjetsbrev, Facebook fansider eller en blog der du jobber med å spisse innhold og budskap. I en sosial kundestrategi vil det være kunden som setter premissene for kanalvalg, i tillegg til at de påvirker og ofte bestemmer budskapet i dialogen. Du kan ikke lenger kontrollere hva budskapet skal være – kun gjennom deltakelse i kundedialogen på kundens premisser vil du lykkes.

Husk – det handler om strategi, ikke systemer

Disse radikale endringene i maktforholdet mellom kunde og bedrift har store implikasjoner for hvordan selskaper må designe sine strategier rundt interne prosesser, organisasjon og teknologi. Det er viktig å huske på at sosial CRM handler om foretaksstrategi. IT-systemer løser ikke alene utfordringene dine. Om ikke organisasjonen og prosessene i bedriften er designet for å håndtere sosiale kunderelasjoner vil innkjøp og implementering av IT-systemer feile.

Disse anbefalingene kan fremstå som trivielle, men jeg tror de er blant de viktigste når man skal implementere sosial CRM. Gartner spår at mer enn halvparten av selskapene som forsøker å etablere en sosial strategi vil feile i implementeringen fordi man mangler en forankring og klare tanker rundt hvordan dette skal være fordelaktig for kunder og selskapene selv.

Hvordan implementerer ditt foretak sosiale kundestrategier? Hva har vært deres største utfordringer og hvordan har dere løst disse?

For å følge dette innlegget vil du sannsynligvis trenge noe kunnskap om JavaScript og / eller jQuery for å virkelig sette pris på fordelene med «deferreds» som jeg skal vise frem med kodeeksempler.

Men først la oss finne ut hva vi skal prøve å løse i dette blogginnlegget.

I JavaScript eksekverer vi koden fra topp til bunn, men det vi ikke ønsker er at koden skal stoppe og vente på API-kall eller en animasjon for at den skal fullføres. Det vi ønsker er at koden skal handle når noe skjer. Dette kan selvsagt gjøres på et par forskjellige måter, men jeg kommer til å vise deg hvordan du gjør det med såkalte «deferred objekter» i dag.

Deferred eksempler:

Så la oss si at vi vil hente ut noe adressedata fra vår egen tjeneste og deretter benytte Google API for å hente enda mer informasjon om denne adressen.

Vi deklarerer våre kall i en funksjon og returnerer vår «deferred». Alle jQuery ajax funksjoner returnerer «deferreds» (eller egentlig ikke, men dette kommer vi tilbake til) som $.get, $.ajax, $getJSON.

var getData = function (data) {
            return $.getJSON(url1);
        };
        var getMap = function (data) {
            return $.getJSON(url2);
        };
        var getMoreData = function (data)
            return $.ajax({
                dataType: "json",
                data: data,
                url: url3
            });
        };

//Get our data and then get our map.

        var map = getData()

                            .then(getMap());

        //After our map is done, we then get more data.

        var moreData = map.then(getMoreData());

        //After more data is done we then log out the result.

        moreData.then(function (result) {

            console.log(result);

        });

var loadAll = $.when(

            getData(),

            getMap(),

            getMoreData()

            );

loadAll.then(

    function () {

        //arguments are [getDataArgs, getMapArgs, getMoreDataArgs]

        console.log(arguments[1][0][0]); //Our map in this case

    }); 

        //Returns a deferred from all calls we did before.

        function loadAll(){return $.when(

            getData(),

            getMap(),

            getMoreData()

            );

        };

        //Defines a function that takes a duration (milliseconds)

        //returns a deferred,

        //sets a timeout for the duration and resolves the deferred

        //after the duration is done.

        $.wait = function (duration) {

            return $.Deferred(function (def) {

                setTimeout(def.resolve, duration);

            });

        }

        //Runs our wait.

        //When our wait deferred comes back resolved we run a function and

        //prints out the arguments.

        $.wait(2000)

            .then(loadAll).then(function () {

                console.log(arguments);

            });

$.superAjax = function (data) {

            //Declare our deffered.

            var def = $.Deferred();

            //Do our if (window.XMLHttpRequest)

            //    xmlhttp = new XMLHttpRequest();

            // and all that good stuff here. But now were only faking it.

            (function () {

                //After 5 seconds we say that we have loaded successfully

                setTimeout(def.resolve, data.loadtime);

            }());//< self running function

       //We done some notify() on the deffered, this calls all

//.done() and .progress() functions with the params specified.

            (function () {

                setTimeout(def.notify, (data.loadtime / 5), 20);

                setTimeout(def.notify, (data.loadtime / 2), 50);

            }());//< self running function

            return def.promise();//Returns our promise, not the deffered itself

        };

        //Get a new superAjax object

        //Our object here only contains our loadtime

        //(would it be awesome if you could specify that!)

        //but would of course in a realworld app contain URL, data, data-type etc.

        var superAjax = $.superAjax({ loadtime: 5000 });

        //Listen to progress on the object

        superAjax.progress(function (message) {

            console.log(message);

        });

        //Callback for when superAjax is done

        superAjax.done(function () {

            console.log("superAjax loaded");

        });

Det skal nevnes at ikke alle sårbarhetene nødvendigvis er så farlig i alle tilfeller. I et bilderedigeringsprogram spiller det mindre rolle at det brukes en dårlig slumptallgenerator (bruk SecureRadom klassen!). Men for et program som gir tilgang til interne systemer i en bedrift, vil f.eks kryptering av sensitive data med hardkodete nøkler være katastrofalt.

Hvorfor er det da slik at så mange apper inneholder feil og sårbarheter? Jeg mener at det ikke finnes et enkelt svar. Flere faktorer spiller inn:

• Relativt ny plattform og uerfarne utviklere
• Dårlig dokumentasjon av de offisielle API’ene. Dette sprer feil informasjon, som bl.a. gir seg utslag i dårlige eller direkte feil svar på brukerforum
• Generell uvitenhet om de spesielle utfordringene ved utvikling på Android
• Manglende fokus på sikkerhet i utviklingsløpet
• Ingen eller lite “Black hat”- testing. Dette er testing der man prøver å ødelegge eller bryte seg inn i applikasjon. Gjerne for å få tilgang til data/funksjoner man ikke skal ha tilgang til.

I denne posten fokuserer jeg spesielt på ett område i listen over, nemlig noen av de spesielle utfordringene ved utvikling til Android. For å få fullt utbytte er det en fordel med grunnleggende kjennskap til Android, men også nybegynnere og testere kan bruke dette som en huskeliste.

En typisk app består av ett eller flere skjermbilder. Disse skjermbildene kan utveksle data ved å sende hverandre meldinger. I tillegg er det mulig å sende disse meldingene mellom ulike app’er. Dette er en av styrkene til Android og gjør det enkelt og effektivt for utviklere å gjenbruke funksjonalitet. Men det kan også åpne opp for litt problemer som vi skal se mer på nå.

1. Forfalskede meldinger (Intent Spoofing)

“Hei, aksjekursen til firma A kommer til å stige 20% i morgen”. Uten å stille spørmål ved avsender og troverdigheten til denne beskjeden handler du mange aksjer i firma A. Scenarioet her er kanskje litt konstruert, men viser problemet med forfalskede meldinger. Mottakeren har ingen beskyttelse. Han burde ha stilt kritiske spørsmål eller undersøke firma A før han handlet.

Slik er det også med Android apper. Om din app ukritisk tar i mot meldinger fra alt og alle, kan en ondsinnet app endre tilstanden i din app eller få den til å presentere gal informasjon, f.eks. feil aksjekurs. Man må beskytte sin app i form av tillatelser som settes i Android Manifest- filen. Da vil din app kun akseptere meldinger fra andre som den eksplisitt stoler på.

2. Uautorisert mottak av meldinger (Unauthorized Intent Receipt)

Denne ligner på punktet over, men nå er det selve meldingen som må beskyttes. Alice ber Bob om å oppgi en hemmelighet, f.eks. et passord. Ved siden av dem står en mindre hederlig person, Mallory. Hun sier “Hei, jeg kan også motta din hemmelig. Fortell den til meg så skal jeg videresende den”. Bob forteller så passordet til Mallory, som sier til Alice at hun ikke mottok passordet, så Alice spør igjen. Bob tenker ikke noe videre over det og gjentar passordet, og Alice er fornøyd. Det Alice og Bob ikke vet er at Mallory nå også har passordet.

Om din app sender ut meldinger som ikke er beskyttet med tillatelser, kan den snappes opp av en ondsinnet app. Dette åpner for mulighet til å endre flyten i et program eller lekke sensitive data. I forhold til eksempelet over er Mallory en ondsinnet app som er installert på telefonen. Når din app (Alice) ber om passord, tar Mallory over og får brukeren Bob til å oppgi passordet. Bob vil anta han tastet feil siden han ikke ble logget inn og  blir bedt om å oppgi passord på nytt. Denne gangen får han logge inn.

3. Manipulerte databasespørringer (SQL Injection)

Alle app’er har tilgang til en egen database for å lagre data. Utviklere må passe på å kontrollere all input som kommer fra kilder de ikke selv kontrollerer og stoler på. Brukerinput, meldinger fra andre app’er, web servicer osv. Husk på å bruke parameteriserte spørringer  og inputvalidering!

4. Usikker lagring (Unsecure Storage)

App’er har mulighet for å lagre data på et delt eksternt medium. Det  kan være et eksternt SD-kort som er satt inn i telefonen, eller telefonens interne lager. Data som lagres her er tilgjengelig for alle! Ikke nok med det, sletter man app’en så blir ikke nødvendigvis filene på det eksterne mediumet slettet! Bruk derfor databaser eller internt lager og marker filene som privat. Dermed blir de kun tilgjenglig for din app og vil slettes når app’en avinstalleres.

5. Vedvarende kringkastingsmeldinger (Persistent Messages: Sticky Broadcast)

Vedvarende kringkastingsmeldinger tilsvarer å rope ut i et rom fullt av mennesker. Kun de som er interessert vil fange opp budskapet ditt, mens resten fortsetter som vanlig. I tillegg blir budskapet ditt lagret, slik at det kan spilles av i fremtiden for nye personer som kommer inn i rommet. Dessverre har også alle mulighet til å slette meldingene, slik at nye personer blir forhindret fra å motta de. Bruker programmet ditt Sticky Broadcast-meldinger risikerer du å kompromittere sensitive data. Derfor er det viktig å kontrollere eventuelle slike meldinger og se hvilken data som blir sendt.

Bruk heller vanlige kringkastingsmeldinger og sørg for å sette på beskyttelse i form av tillatelser.

6. Usikker kommunikasjon (Insecure Communication)

Mange gjør feilen å tro at fordi man benytter en mobiltelefon, blir det vanskeligere å avlytte kommunikasjonen. Det er ikke tilfelle! (Det er faktisk mulig å lage sin egen basestasjon for å avlytte mobiltelefoner). I de fleste tilfeller er det like enkelt som å avlytte en web-applikasjon. Derfor bør dine mobil-apper behandles og sikres på samme måte som web applikasjoner. Benytt HTTPS (kryptert kommunikasjonsprotokoll) hvis mulig og kjør tester hvor du inspiserer trafikken, for å sikre at sensitive data ikke blir sendt i klartekst.

7. Unødvendige tillatelser (Overprivileged applications)

Dette er ikke så mye en sårbarhet,  men mer dårlig praksis. Ulike operasjoner i Android er beskyttet av tillatelser som må settes i en egen manifestfil. I utviklingsfasen vil en gjerne få ting til å fungere raskest mulig. Derfor hiver en ukritisk inn tillatelser, og ender opp med en app som har tilgang til alt for mye. Dette er med på å forvirre forbrukere, og de vil bli mindre kritiske til å studere hvilke tillatelser de aksepterer. De blir rett og slett vant til å ignorere hvilke tillatelser en app spør om. Dette bryter ned et av Androids viktigste forsvarsmekanismer og åpner døren for ondsinnete apper.

Til slutt vil jeg prøve å komme med noen punkter som kan følges for å lage gode, sikre apper:

• Tenk sikkerhet fra begynnelsen av. Gjør en trusselvurdering og finn passende sikkerhetsnivå for din app.
• Bruk TDD (test drevet utvikling) for å sikre kvaliteten.
• Gjør deg kjent med Android sin arkitektur og hvordan OS-et fungerer.
• Bruk minimalt med tillatelser. Skriv gode forklaringer, gjerne på flere språk, som forklarer hvorfor du trenger akkurat de tillatelsene.
• Før publisering, kontroller at det ikke finnes noen hemmeligheter som passord eller hardkodete nøkler i kildekoden. Husk at denne sendes ut til brukerene og det er lett og dekompilere en Android-app.
• Gjør sikkerhetstesting. Tenk som en angriper og se hva du kan få din app til å gjøre.

Jeg håper dette kan bidra til bedre og sikrere apper. Kom gjerne med tips og innspill i kommentarfeltet!

Bakgrunn
La oss som bakgrunn for dette tenke oss et prosjekt som har som mål å utvikle en webapplikasjon for en kunde, med en total varighet på ca. ett år. Webapplikasjonen skal bestå av et sett med ti use cases, alle modellert med ett eller flere skjermbilder med tilhørende forretningsfunksjonalitet. Prosjektet skal leveres med en målprismodell. Spørsmålet er da; hvordan vil disse faktorene påvirke arbeidet i tilbudsfasen?

Arbeidet i tilbudsfasen
Under tilbudsfasen skal det utarbeides et grovdesign som danner basisen for et estimat. Her er det fort gjort å komme litt skjevt ut – hvordan skal man kunne estimere en slik relativt ukjent oppgave? I vårt tilfelle hadde vi gode erfaringstall fra tidligere prosjekter.  Disse estimatene ble så ytterligere forfinet i samråd med erfarne teknikere for å  sikre at levert estimat skulle være så korrekt som mulig. Detaljeringen og videre estimering utover dette grovestimatet ble utsatt til implementasjonen.
Det som er veldig viktig når estimatene utarbeides er at man går i tilstrekkelig detalj for use casene som skal implementeres under prosjektet. Det er også viktig å ikke glemme bort ikke-funksjonelle krav under estimering. Faktorer som testing, ytelse, dokumentasjon og infrastruktur hos kunden varierer en hel del og kan ofte vise seg å være minst like tidkrevende å få på plass som de funksjonelle kravene.

Prosjektgjennomføringen
Armert med gode estimater, et godt team og med en smidig utviklingsprosess så har man skaffet seg et veldig godt utgangspunkt for prosjektgjennomføringen. Jeg mener at det som vil ha den største påvirkningen under prosjektet er at dette er et målprisprosjekt. Dette betyr at man er innstilt på å levere prosjektet innenfor en forutsatt tidsramme basert på de estimatene som ble levert i tilbudsfasen. I et slikt tilfelle vil det etter min erfaring få følgende konsekvenser for Scrum-prosessen i prosjektet:

1. Scrum-prosessen som blir kjørt i prosjektet er som vanlig, med sprintplanlegging, standups, demo for kunden og retrospektiv for hver sprint. I sprintplanleggingen vil verdien av oppgaveestimeringen bli redusert. Poenget med estimeringen under sprintplanleggingen er å produsere et så korrekt estimat som mulig.  I et målpris prosjekt er estimatene fra tilbudsfasen de  som prosjektet blir målt opp mot og dermed de man sikter mot. Konsekvensen av dette er at teammedlemmene ikke til fulle kan påvirke estimatene. Dette kan etter min erfaring ha en negativ effekt på “team commitment”-følelsen som er svært viktig i Scrum-tankegangen.

2. Et målprisprosjekt kan også få konsekvenser for teamets fremdrift (velocity). Teamets fremdrift beskriver hva som kan forventes levert innenfor en fremtidig sprint basert på statistikk fra tidligere sprinter. Målpris prosjekt vil som oftest føre til at man har et veldig rigid timebudsjett som vil gjøre at man til dels har forhåndsbestemt innholdet i en sprint. Dette igjen bryter mye av tankegangen rundt bruken av smidig metoder. Det er jo det at man kan justere innholdet i sprinten som gjør at man kan få løst de endringer og utfordringer som oppstår underveis.

Oppsummering
Oppsummert så kan prosjektform og valg tatt i tilbudsfasen ha en stor effekt på prosjektgjennomføringen og Scrum-prosessen.  Ideelt så ønsker man en Scrum-prosess som ligger tett opp til måten den er beskrevet på  i litteraturen, og dermed få mest mulig ut av både estimering, fremdrift og lignende. For at dette skal fungere er man imidlertid avhengig av friheten til å kunne utføre endringer underveis.  For prosjekter der en slik smidig tankegang ikke er mulig av praktiske årsaker, vil dette begrense verdien av å kjøre prosjektet etter Scrum-metodikken.

Det gjaldt å ha god kontroll med hva som slapp inn gjennom portene, og å sikre seg at en inntrenger ikke fikk tilgang til, og dermed kontroll over hele borgen, bare ved å komme på innsiden av den ytre muren. Man måtte også sikre seg at livsnødvendige forsyninger slapp inn uansett hvor stor trafikk det ellers var, og at kommunikasjon med vennligsinnede naboborger ikke ble avslørt hvis en kurer ble tatt til fange eller gikk over til fienden.

Når det gjaldt lagring av mat og drikke, våpen, ammunisjon og utstyr ellers, så måtte det både være nok plass og tilstrekkelig sikring av lageret. Alle som holdt til innenfor murene kunne ikke ha samme tilgang til alt som var lagret. Noe trengte å sikres ekstra godt, slik at det ikke ble ødelagt av misbruk eller forurensing. Og det var ikke de samme som hadde tilgang til vinkjeller, kornlager og kruttkammer.

Skulle slike krav til sikkerhet bli oppfylt måtte de tas hensyn til allerede når byggene innenfor borgmurene ble planlagt, ellers ville de bli såpass kostbare å få på plass at det i praksis var for sent. Når det skulle oppføres en ny bygning måtte den tilpasses de bygningene som er der fra før, og oppfylle de samme krav til byggematerialer og konstruksjon som gjaldt for eksisterende bygninger.

Analyse

På samme vis må man ved utvikling av datasystemer ta sikkerhetshensyn helt fra starten av. Og før det er laget systemmoduler som kan testes, må kravdokumenter, løsningsforslag og plantegninger kunne gjennomgås og sjekkes for å verifisere at det er tatt hensyn til krav til sikkerhet. For å sitere Capers Jones, amerikansk ekspert på kvalitet i programvare:

“Først inspeksjon, så inspeksjon, så inspeksjon, så inspeksjon, så testing”.

Erfaringsmessig er det mye å spare på at avvik fra krav blir oppdaget så tidlig som mulig, og dette gjelder i minst like stor grad ved sikkerhetskrav som ved rent funksjonelle krav. Avvik fra sikkerhetskrav kan få konsekvenser som ofte er større både for omdømme og økonomi enn avvik fra funksjonelle krav.

Inspeksjoner

Ved gjennomganger og inspeksjoner er det viktig at deltagere har nødvendig kompetanse, slik at de kan gjøre seg opp en oppfatning om det er noe som mangler, om alle krav er oppfylt og om den beskrevne løsningen passer inn sammen med eksisterende systemer.

Etter hvert som krav og løsningsforslag blir godkjent og realisert som programkode, bør også denne inspiseres. Ved sikkerhetstesting gir statisk analyse og kodegjennomgang erfaringsmessig stor gevinst, og det er omfattende verktøystøtte for dette, både av gratis og kommersiell programvare. Slike analyseverktøy kan avsløre om koden er sårbar for flere av de mest brukte metodene for å omgå sikkerhetsbarrierer, som SQL-injeksjon og cross-site scripting.

Testing

Testing av sikkerhet blir gjerne beskrevet som forsøk på å trenge gjennom sikkerhetsmekanismene for å avsløre mangler, og det er svært viktig at både hva som skal testes og når det skal testes er avtalt og avklart med prosjektledelsen. Vi kan ikke forestille oss at vaktstyrken i en borg spurte om det var en test når de ble utsatt for et angrep, og på samme måte må vi forvente at de som jobber med sikkerhet i en bedrift tar et angrep på fullt alvor hvis det ikke har blitt avtalt med dem at en test skal gjennomføres.

Hvis det er gjennomført inspeksjoner og gjennomganger på flere nivåer, vil man kunne konsentrere selve testingen mer på å sjekke andre mulige sikkerhetsavvik enn om systemet er sårbart for ondsinnet input. Slike avvik kan være at passord lagres ukryptert, at brukertilganger ikke er tilpasset behov, at filer og databaser kan leses av uvedkommende, eller at kommunikasjon med omliggende systemer er ukryptert.

Big data har i lengre tid vært omtalt som et banebrytende verktøy for kundesegmentering og markedsføring. Social Media Analytics går ofte igjen når man snakker om hvordan man kan hente ut verdi fra Big Data. Her kan en hvilken som helst bedrift eller organisasjon hente ut detaljert og innsiktsfull informasjon fra Twitter eller Facebook med de rette verktøyene for hånden. Men hvorfor har dette blitt Ola Nordmanns oppfattelse av Big Data?

Jeg tror det store fokuset på quick-wins som for eksempel kundesegmentering eller sentimentanalyse har gjort at bedrifter som ikke er like opptatt av å måle forbrukerens oppfattelse av merkevaren ofte ser på Big Data som en hype, istedenfor å se på hvilke andre muligheter som ligger der.

Et Google søk på de to ordene ’Big data’ gir 1 250 000 000 treff på 0,29 sekunder. Og et av de første treffene som dukker opp er ”What is Big Data?” Så det er kanskje greit å starte her.

Big Data er en term som har vært i vinden lenge og de lærde strides fortsatt om en enhetlig definisjon. Big Data betyr en ting for noen, og en annen ting for andre – men litt for ofte er det bruk av data fra sosiale medier som er gjengangeren.

En definisjon som går igjen er at Big data er en samling av datasett som er så store og så komplekse at de vanskelig lar seg lagre, håndtere og analysere av tradisjonelle databasesystemer. Disse datasettene identifiseres gjerne ved hjelp av de 3 v’ene som ble presentert av Meta Group(nå kjent som Gartner) i 2001 i forbindelse med problematikken rundt datavekst.

1.     Volume

Data hentes inn både innenfor og utenfor brannmuren, og overgår datamengder som vi er vandt til å håndtere. Big data har heller ikke noen klart definert størrelsesorden utover at det er datamengder i større volum enn hva vi tradisjonelt hanskes med. Det kan for noen være Terrabytes, men for andre Peta- eller Zettabytes.

2.     Velocity

Big Data kan også identifiseres ved hastigheten på dataen som fanges opp. Man kan vel kanskje si at det handler om raskere data enn hva vi kjenner til fra tradisjonell Business Intelligence. Sensorbaserte data måles gjerne i intervaller på få sekunder, og ved denne hyppigheten genereres det etter hvert uhorvelige mengder data. Ta for eksempel CERN i Sveits, som produserer én Petabyte av forskningsdata hvert eneste sekund. Her er det helt klart ikke mulig å ta vare på all dataen, og de må derfor fange opp de bitene med data som faktisk er av interesse. Så selv om de forkaster store deler ender CERN opp med å produsere 25PB hver dag, noe som tilsvarer 525 948 766 minutter, eller 1000år med video av DVD-kvalitet.

3.     Variety

Variety handler om både strukturert, semi- og ustrukturerte data som vi først tar stilling til hvordan vi skal bruke etter at vi har lagret det. Det er så opp til algoritmer og ulike modeller å fange opp hvilke mønstre som finnes. Eksempler på slik data kan være rådata fra RFID-brikker, geografiske lokasjonsdata, bilder og tekst.

Det er nå godt over 10 år siden Gartner introduserte disse tre v’ene. Derfor har jeg også lyst til å trekke inn to andre faktorer som er med på å danne grunnlaget for det vi i dag omtaler som Big Data:

4.     Variability

Data kommer altså i større volum, i større hastighet og i fler formater enn tidligere. Men hyppigheten varierer også i større grad når man begynner å trekke inn data som befinner seg utenfor brannmurene. Under den første amerikanske presidentdebatten i 2012 økte antall tweets om valget til hele 114.000 tweets i minuttet og ente opp på hele 10,3 millioner i løpet av den 90 minutter lange TV-sendingen før den etter hvert havnet tilbake på normalen.

5.     Versatility

Versatility handler mer om at enhver aktør som har tenkt til å se nærmere på Big data bør ha IT-systemer i bunn som kan takle dette på en agil måte. Det gjelder altså å ha databaseteknologier som gjør det mulig og ikke bare løse enkeltoppgaver, men også utforske nye interessante sammenhenger som dukker opp underveis, avhengig av hvilke funn du gjorde ved den første spørringen.

Big Data er fortsatt et Buzzword som vi ikke helt har klart å bli enige om hvordan vi skal definere. Og mange er nok lettere irritert over et «Big er bra» argument.

Min mening er at Big Data ikke bare handler om å samle, håndtere og prosessere data i et større volum, med høyere hyppighet og i nye formater enn med tradisjonell Business Intelligence.  Men også smartere bruk av denne dataen. Big Data må i dag dreie seg om reelle og krevende forretningsbehov og et større konkurransefortrinn enn allerede godt kjente metoder som tekstmining som surfer avgårde på et nytt Buzzword. Kall meg gjerne optimist, men når jeg tenker Big Data ser jeg for meg «Video-piller» og realtime sensordata for raskere og bedre diagnostisering av pasienter, Urban Informatics – der store urbane knutepunkter måles og optimaliseres for en sømløs harmoni mellom analog og digital infrastruktur.

Se for eksempel på våre kjære naboer ved universitetet i Uppsala. Der har de igangsatt et nytt Stream Computing prosjekt for å analysere massive volumer av data i real time for å bedre forstå seg på værforholdene i galaksen. Løsningen analyserer nærmere bestemt 6GB data per sekund.  Rett nord for Stockholm forsøker forskere å måle høyfrekvente radiostrålinger for å kunne predikere en værmelding for rommet, men samtidig måle effekten av plasmautbrudd på solens overflate.

Plasmautbrudd og høyfrekvente radiostrålinger som treffer jorden har en negativ påvirkning på energioverføring via strømnettet, radiokommunikasjon, TV-signaler, satellitter, rom- og luftfart. Ved å kunne «forecaste» og «nowcaste» hvor og når en magnetisk storm vil treffe jorden får man muligheten til å reposisjonere kostbare satellitter, iverksette preventive tiltak på strømnett og annet sambandsmateriale.

Big Data er altså et begrep som vanskelig lar seg definere og debatten raser av sted med artikler som Why We Need To Kill “Big Data” og Big Data : The Next Big Thing. Men som jeg begynte med, Big Data har forskjellig betydning for ulike personer. For meg er det hvordan vi kan utnytte all den tilgjengelige dataen på en bedre eller smartere måte, for eksempel hvordan sensorbasert data fra T-banestasjoner kunne ført til dynamisk oppsett av vognsett, slik at vi alle hadde sitteplass på vei til eller fra sentrum.

Så neste gang du leker med ordet «Big Data», glem Facebook og Twitter. Tenk heller over hvordan du kan gjøre noe smartere enn dine konkurrenter!

Engasjement skaper verdier. Så lenge retningen er noenlunde riktig vil engasjerte medarbeidere nå sine mål raskere og bedre enn sine passive motstykker. Tilsvarende kan økt engasjement fra kunder resultere i tettere relasjoner, økt lojalitet og reduserte kostnader.

Det er dermed ikke så overraskende at evnen til å skape og drive engasjement er ettertraktet i dagens marked. Det har fått flere til å bli inspirert av arenaer som er viden kjent for engasjement, deriblant sport og spill. Et av de nyere digitale moteordene har sitt opphav derfra, nemlig Gamification – bruk av mekanismer fra spill for å fremme ønsket atferd i aktiviteter som ikke er spill. Kjente eksempler på spillmekanismer er poeng, progresjon og prestasjoner. Poeng tildeles typisk etter fullførte oppgaver, progresjon synliggjør avstand til mål og prestasjoner er bevis for hele verden at man har oppnådd mål.

Paul Moxnes

Det er et viktig møte med kunden i morgen. Etter timer med flikking på rapporten, er du fornøyd. Nå gjenstår bare en god natts søvn. Rett etter du har krabbet under dyna, får du flere ideer. Du må opp for å skrive dem ned. Nå er det klart for søvn, må jo være frisk og rask i morgen. Klokka blir ett, men du har fortsatt mange gode ideer. Dette blir SÅ bra, tenker du fornøyd. Klokka blir to. Du begynner å bli litt urolig. Jeg må sove nå. Får jeg ikke sove nå, så… Når klokka er tre begynner panikken å bre seg. Jeg kommer ikke til å gjøre det bra i morgen! Kan jeg bli tatt ut av prosjektet etter min begredelige prestasjon under møtet? Det blir i så fall begynnelsen på slutten av min karriere. Klokka nærmer seg halv fire, og midt inne i din egen villfarelse om hvor stor en skandale morgendagen blir, slumrer du inn. Når klokka vekker deg noen timer senere, spretter du opp. Klar til kundemøte. Fokusert og overraskende lite trøtt.

Noen som kjenner seg igjen? Supert, det betyr at du er helt normal. Dette er helt vanlige menneskelige følelser. Dette er angst.

Angst? Ja, angst.

La meg først som sist presisere følgende: Det er ikke angst som panikk og tvangslidelser jeg snakker om. Jeg snakker om hverdagsangsten – den redsel, uro og nervøsitet vi kjenner i arbeidsliv og sosiale situasjoner. Angsten som skyldes situasjonsbetinget stress, som befester seg med forbigående perioder med søvnproblemer, kvalme, eller rett og slett svette hender, hoppende hjerte og gelé i beina. Organisasjonspsykolog Moxnes kaller det for henholdsvis kald og varm angst.  Det er den varme og positive angsten Moxnes har promotert i flere år som jeg vil ha opp og frem på agendaen.

Hva er du redd for? Jeg er redd for en rekke saker. Ikke innfri overfor han som ansatte meg, er en, at jeg ikke klarer å løse oppgavene jeg påtar meg, er en annen. Mest av alt er jeg redd for presentasjoner og intervjuer der det er forventet at jeg skal gjøre meg struttende og gjeldende. Er jeg et svakt menneske? En bunt full av nerver og manglende selvtillit? Det er gjerne det vi blir lært opp til å tenke. Angst er for de svake og overfølsomme. Angst er et symptom på noe underliggende og grunnleggende feil. Vi lærer raskt å skjule angst overfor kollegaer, kunder og ikke minst – oss selv. ”Ta det som en mann”, med andre ord, løs oppgaven uten å vise redsel. Det er disse oppfatningene jeg vil til livs!

Det store spørsmålet er: Hvordan forvalte angsten din så det gir deg ekstra energi og fokus? Unngå at angsten står i veien, paralyserer og kan få deg til å senke ambisjonsnivået ditt? Moxnes gir følgende råd:

Vedgå angsten og aksepter at den er der!  Min erfaring tilsier at jeg ikke blir mindre redd av å late som om jeg ikke er redd. Snarere tvert imot, fordi jeg bruker energien min på å finne ut av hvorfor jeg er redd og ergrer meg. Jeg har akseptert at redd kan jeg tidvis bli, med alle sine merkelige utslag. Nå setter jeg pris på angstens inntog fordi jeg vet det er en viktig kilde til energi. Jeg har også akseptert at jeg aldri kommer til å ”helbrede” eller bli kvitt angsten min så lenge jeg prøver å gjøre ting jeg ikke kan. Jeg forvalter ikke angsten min perfekt i dag, men jeg blir stadig bedre.

Gjør ting du ikke vil til et MÅ. Så lenge det er en mulighet for å velge den feige veien (dette kan eller bør jeg), er det lett å ta den. Eliminer mulighet for en annen utvei med et standhaftig MÅ. Finn noe av høy verdi for deg, og sett det mot dette. Dette kan være med hensyn til eget liv og utvikling, til dine barn, lojalitet til organisasjonen osv.

 Identifiser en trygg base du kan lande på innimellom.  Angst er energi, men vi trenger trygghet for å vokse og tørre å ta nye skritt.

 Sist, men ikke minst, gjør det du er redd for om og om igjen. Og enda en gang til.

Har du kjent på kroppen din når du må gjøre noe du er redd for? Hvor fokusert og energisk angsten kan gjøre deg? Min usikkerhet om hvorvidt jeg er god nok, får meg til å si ja-takk til alle oppgaver som blir sendt min vei. Min tvil om jeg klarer å løse oppgaver jeg har påtatt meg, får meg til å jobbe litt hardere. Gang på gang. Når jeg får mulighet til å lede et viktig prosjekt, er jeg redd, tidvis søvnløs og kvalm, men jeg er også veldig lykkelig. Jeg får ut angsten min i engasjement og handling. Jeg presterer bedre. Jeg kunne ha tilstrebet å være minst mulig redd, men da hadde jeg ikke lært mye nytt.

En merkelapp med ANGST i panna er noe de fleste vil unngå, meg selv inkludert. Så hvorfor bruke en så forhatt definisjon på følelser de aller fleste kan kjenne seg igjen i, men ikke helt vil vedkjenne seg? Jeg vil at flere skal vite at angst er en vanlig, menneskelig følelse. Forbigående søvnløshet, katastrofetanker, kvalme og svette når du gjør noe utenfor din komfortsone er en naturlig del av vårt følelsesspekter, og ikke en sykdom. Jeg applauderer Moxnes når han retter en pekefinger mot helsevesenet og legemiddelindustrien som tidvis sykeliggjør og behandler hverdagsangsten. Det burde være allment å kunne anerkjenne og mestre angst, fremfor slik det er i dag: gjemme, diagnostisere og medisinere all angst- også den positive.

Min siste oppfordring er:

Til deg som mestrer angsten din: Fortell hvordan til din neste

Til deg som er leder: En forutsetning for å få mestringsorienterte medarbeidere som vil vinne, er å ha en trygg base. Gi de ansatte trygghet ved å la dem prøve, gi rom for å feile og ta angst som et tegn på et bankende hjerte som ønsker å gjøre det bra! Redselen for nederlag må ikke bli større enn trangen til å lære.

Til deg som tror du er hevet over angst: Når utsatte du deg selv for endringer sist, noe nytt?

Til deg som frykter du er syk: Les Moxnes.

 NB! En forkortet versjon av denne bloggposten var også på trykk i Ukeavisen Ledelse.

Referanse: Paul Moxnes (2012) Positiv Angst i individ, gruppe og organisasjon. Et organisasjonspsykologisk perspektiv. 4 versjon.

Nå skal ikke jeg fortelle om alle mulige forkortelser og buzzer som kan dukke opp på quizer, salgsmøter eller i fluffy foredrag og presentasjoner. Men jeg vil se litt nærmere på en, SPA, eller Single Page Application som det er forkortelse for i denne sammenhengen.

Hva er SPA?

Kort fortalt er SPA en betegnelse på en web-applikasjon som kun operer med en side, og i hovedsak laster all informasjon som siden trenger i seg selv med en page-load, slik at brukeren får en mye mer brukervennlig opplevelse. Det vil ikke si at man laster all tenkelig data en bruker kan komme til å trenge, men det man initielt trenger for å bruke applikasjonen. Så laster man heller stadig mer nødvendig data avhengig av bruk og input.

Men hva betyr dette egentlig?

Først vil jeg prøve å forklare konseptet med “page”. Opprinnelig tillot en nettleser deg å navigere fra dokument til dokument, eller såkalte “pages”. En enkelt page var et fullverdig og komplett HTML-dokument som viste brukeren informasjon. Opp igjennom årene kom det til styling o.l. i form av bl.a. CSS, og man hadde et konsept med webforms, som var nettleserens måte å kommunisere data tilbake til serveren på. Etter hvert kom det til flere og flere teknologier og teknikker (javascript, xml osv.). Dette gjorde at man fikk såkalt dynamisk html, en side som reagerte og forandret seg ved brukerinnput, uten en server-roundtrip (form-post), for å generere en ny html-side. Ved å utvikle og koble sammen en del av disse “dynamisk-html”-scriptene og modulene fikk  man det vi i dag kaller en web-app. Dette er en veldig overordnet og simpel tolking av det hele, men tanken bak SPA er altså ikke noe “nytt” som plutselig dukket opp. Idéen om en page som dynamisk oppdaterer seg og lever i en “self-contained” state, har levd siden tidlig 2000-tallet, og termen SPA er først dokumentert brukt av Steve Yen i 2005.

En av de tidlige og mest kjente web-appene som kan ses på som en SPA, er Gmail, som kom i 2005. Gmail bruker ikke forms for å sende informasjon tilbake til en server for å genere en ny visningsside, men sofistikerte og avanserte JavaScript som kommuniserer med serveren i stedet. Denne teknikken heter AJAX (Asynchronous JavaScript and XML) og er i dag en temmelig kjent og mye brukt standard blant webutviklere.

Noe annet som er greit å se på, er et pattern som understøtter SPA, nemlig MVVM (Model, View, ViewModel)

MVVM er i hovedsak et seperation pattern og passer utmerket til web-app­-utvikling. Som MVC fokuserer det på å separere businesslogikk og  presentasjonslogikk. Viewmodellen brukes til å holde en «temporær» state av modellen som ligger på klientsiden. Den vil typisk eksponere ønskede egenskaper som presentasjonlaget bruker for å vise sluttproduktet. Modellen i sin del har ansvar for businesslogikken og de tjenester som skal tilbys.  

Det gjør at en interaksjonsdesigner i hovedsak kan fokusere på viewet og UX f.eks. ved HTML eller XAML, mens han smidig kan forholde seg til endringer og ønsker fra sluttbrukeren uten å bekymre seg stort over rippleeffekter ned i businesslaget. Mens en back-end utvikler kan fokusere på domene-modellen, POCO, JSON eller hva det måtte være og dens tilhørende businesslogikk, hvor ønskende operasjoner eksponeres i forskjellige endepunkter. En slik “seperation of concerns” tankegang gjør at de som jobber på de forskjellige lagene i løsningen ikke er like avhengige av hverandre og man kan få et mer smidig samarbeid.

Hvorfor SPA nå?

Brukeropplevelse og flyt er blitt mer og mer fremtredende og viktig ved applikasjonsutvikling de siste årene, og det har kommet mange nye plattformer som også har kastet seg på applikasjonsbølgen. Det blir stilt stadig høyrere krav til sømløshet, tilgjengelighet, responsivitet, og sluttbrukere er blitt mer utålmodig når det kommer til å vente på nettverkstrafikk.

Så ved å bruke f.eks. MVVM, SPA-tankegangen, Microsoft WebApi, AJAX, jQuery, andre javascriptbiblioteker som knockout og backbone, bare for å nevne et fåtall av kombinasjoner, kan man gi sluttbrukeren en bedre opplevelse. Ved hjelp av en modell som ligger på klientsiden, template/modul-views for visning og JavaScript e.l. for å bytte ut ønsket visningsdata, i tillegg til at man i initielt laster opp det mest nødvendige som skal vises, kan man møte mange av de økende kravene.

Jeg har kun skrapet på overflaten til dette konseptet, men hvis det er av interesse og man ønsker et mer teknisk dypdykk, kan jeg på det varmeste anbefale et par Pluralsightvideoer av John Papa. Single Page Apps with HTML5, Web API, Knockout and jQuery og Building HTML5 and JavaScript Apps with MVVM and Knockout. Ellers er det bare å kaste seg rundt og begynne å leke!

I et IT-selskap virker det som det er en evig diskusjon hva som skal komme først i et IT-prosjekt.  Noen mener vi diskuterer høna og egget eller hva som er framme og bak på en tradisjonell trykkerimaskin. Dette er et argument for å inkludere usability tidlig i prosjektet.

Alle prosjekt blir til på grunn av et eller annet behov eller en problemstilling. Hva som er behovet varierer – men vi har alltid et behov, en sluttbruker eller mottaker, og en avsender eller oppdragsgiver. I tillegg til behov har alle prosjekt et mål. De fleste prosjekt har også en strategi som forteller hvordan målet skal nås og behovet dekkes.

Konsulenter som jobber med eksterne nettsteder opplever at de må ta andre hensyn til design, kommunikasjon og usability enn konsulenter som jobber med interne løsninger. Årsaken er normalt at kunden setter strengere krav til branding, brukervennlighet og relevans. Et eksternt nettsted skal ofte fremme salg, noe som gjør det enkelt å måle suksess.

Det er tilsynelatende ikke like enkelt å måle suksessen til et timeføringssystem eller et tilsynssystem, men det bør likevel gjøres. Vi finner alltid noe relevant vi kan måle. Vi klarer alltid å finne ut om en løsning gir verdi og hvor stor verdiøkningen eventuelt er.

For å få til en verditilføring eller en verdiøkning må vi gjøre en del enkle grep. Jeg har aldri opplevd en IT-løsning som er så teknisk suveren at det ikke er behov for usability. Det er som å konstruere en Formel 1 racerbil med tilhengerfeste, dieselmotor og hundebur. Det blir lite relevant og mye støy.

Tenker du usability først får du vite hva målgruppen finner relevant og hva sluttbrukerne av løsningen har behov for. Ved prosjektoppstart av et suksessprosjekt møtes prosjektleder, business analyst og usability analyst. Sammen setter de opp prosjektplan og skisse, men først gjennomføres det en målgruppeanalyse.

En målgruppeanalyse forteller oss hva løsningen bør inneholde og hvordan løsningen bør fungere. Alt handler om relevans og behov. Vi spør aldri hva målgruppen har lyst på eller hva de ønsker. Vi snakker ofte om tre hoveddeler:

1. Grunnforståelse av målgruppen (mottaker/ bruker)
2. Grunnforståelse av kommunikasjonsprosessen
3. Forhold som kan påvirke kommunikasjonsprosessen

Resultatene fra målgruppeanalysen krysses med avsenders mål. Dette danner grunnlaget for den første prosjektskissen. Vi skal ikke glemme å være kreative og innovative, for målgruppen kan kun svare på spørsmål de vet svaret på. Kjenner vi målgruppen godt har vi gode forutsetninger for å kunne foreslå nytt innhold og nye funksjoner.

Noen ganger er det bestemt hva slags teknisk løsning som skal lages, men teoretisk sett bør målet avklares før vi tenker teknisk. Vi ser stadig vekk løsninger som er hightech, men som er laget for å håndtere enkle oppgaver. Begynner vi i motsatte ende er det enklere å lage en teknisk løsning som passer prosjektmålet.

Usability er for mange synonymt med brukervennlighet. At ikke alle IT-løsninger er brukervennlige synes jeg er merkelig. Det koster lite eller ingenting ekstra i tid og penger. Det handler kun om prosess og prioriteringer.

La oss se litt på brukerinvolvering. Vi snakker da om intervjuer og brukertester hvor vi trekker inn målgruppen. Vi bør så tidlig som mulig sjekke med målgruppen om det vi planlegger er i tråd med målgruppens behov. Vi bør sjekke om funksjoner er intuitive og relevante. Får vi ”godkjenning” fra målgruppen tidlig i prosjektet er det mye enklere for prosjektleder og prosjektmedlemmer å styre mot en nyttig og verdiskapende løsning.

Brukertesting kan gjøres på mange måter. Før løsningen er påbegynt, bruker vi skisser eller prototyper i brukertestingen. Både intervjuer og brukertester kan gjøres som korte avsjekk eller lange, grundige tester. Antall brukertester er ikke det som automatisk avgjør om resultatet blir bra eller ikke. Det beste er å teste til du ikke lærer noe nytt og resultatet av testen ikke varierer stort.

Usability handler også om design, innhold, navigering og brukervennlighet. Det finnes en rekke regler og anbefalinger i forhold til brukervennlighet. Jobber du med et offentlig prosjekt bør du ha universell tilgjengelighet i bakhodet. Generelt er det en designer, interaksjonsdesigner eller innholdsstrateg som passer på at løsningen blir brukervennlig og tilpasset målgruppen. Det siste er det viktigste, spesielt når vi snakker om interne løsninger.

Det hjelper lite om det sitter en designer og rir på generelle retningslinjer for brukervennlighet hvis målgruppen er ukjent. Løsninger må tilpasses målgruppen, også teknisk. Det finnes et fantastisk begrep som kalles livsverden. Vi er ikke flinke til å bruke det i Norge, men våre  dyktige venner i Danmark snakker ofte om livsverden. Livsverden dreier seg om forhold ved brukeren som kan påvirke hvordan han eller hun bruker løsningen.

Livsverden kan være med på å styre hvor intuitiv en løsning må være for å bli adoptert av målgruppen. Det er som regel adopsjon av innovasjonen det handler om til slutt. Det er enklere å sette tall på adopsjon i forhold til eksterne løsninger. Interne løsninger er ofte verktøy som ansatte må bruke for å kunne utføre jobben sin. Det beste er mange ganger å sette opp tilbakemeldingsintervju i etterkant og brukerteste alt vi orker underveis i designprosessen.

Usability er med andre ord en måte du kan kvalitetssjekke løsningen allerede før den er laget. Du skal selvsagt aldri glemme høy teknisk kvalitet, hastighet, teknisk testing og alle de andre tingene vi er flinke til. Usability betyr bare at den tekniske løsningen blir opplevd som spissere og mer relevant for målgruppen.