Big Data - Hur BIG kan det bli?

“Big Data” är hype men hur stor kan det bli? Vilka kommer att tjäna pengar på detta?

“Big Data” är ett ganska nytt begrepp för att utvinna och härleda information ur stora datamängder. Tidigare har begreppet “data mining” används för att beskriva detta. Men “data mining” har oftast varit kopplad till att analysera det data man “råkar” ha, inte som man mer strategiskt samlat in för att kunna göra bättre analyser.

Om vi tar upp perspektivet leverantör-kund så kan man med “data mining” hitta mönster i vad kunder har köpt och vad potentiella kunder har frågat efter eller vilket mönster de haft när de besökt din hemsida. Du kan med detta underlag kan du anpassa ditt erbjudande.

Men...

Du har svårt att av de data du har tillgång till lära känna din kund utöver den relation ni har. Vilka konkurrerar du med om kundens gunst? Hur är kundens förhållande till dessa? Vad har kunden för andra intressen och hur kan dessa korsa dina? Detta har du svårt att veta utifrån de data kunden lämnat hos dig och din analys blir svår.

Men vilka kan göra en bättre analys om dina kunder än du själv kan? Jo de som vet mer om dina kunder än du själv vet. De som kan se relationen från båda sidor har ett klart övertag. Idag är det få aktörer som är stora på detta, främst är det  Google, Facebook, välfungerande underrättelsetjänster m.f. som sitter på mycket mer data än vad du själv kan samla in. Förmodligen kommer det snart gå att köpa analyser från flera av dessa gigantiska datalager men att köpa obearbetade data för egna analyser blir nog svårare.

Min slutsats är att Big Data bara blir BIG för de allra största.

Det kostar att ha otur när man tänker

Systemutveckling i sammanhanget utveckling av IT-system härrör sig (förhoppningsvis) från en intention i att utveckla någon form av verksamhet m.h.a. IT så att den upplevs bättre. Bättre lönsamhet, effektivitet, produktivitet, miljömässigt eller arbetsmiljömässigt eller anpassning till yttre krav. Intentionen bör vara uttalad och följa genom de projekt som startas.

Utöver projektens mål d.v.s. en formaliserad beskrivning av intentionerna sätts också ramar upp för de projekt som startas. Ramarna består ofta av en tidsplan, med eller utan delmål,  och en beskrivning vilka resurser som projektet får tilldelat.

Ett övergripande sätt att beskriva de steg ett utvecklingsprojekt för verksamheten kan vara:

Ursprunglig verksamhet                        Förändrad verksamhet

Idé--> Design--> Kodning--> Integration--> Leverans--> Förvaltning

Vad som är känt är att ju tidigare ett tankefel introduceras (som inte ifrågasätts och åtgärdas löpande) i projektet ju högre blir kostnaden för att åtgärda felet.

Konceptuella fel, designfel eller kodbuggar beror på “den mänskliga faktorn”, någon har haft otur i sitt tänkande.

För att fånga fel används tester och metoder för test utvecklas löpande. Men... avståndet i tid mellan att ett fel introduceras tills att det upptäcks med hjälp av tester kan vara ganska lång.

Etablerade testmetoder hanterar i huvudsak den kod som levereras i samband med leverans av delar eller hela systemet.

Designfel kanske inte upptäcks förrän integrations- eller leveranstester görs. Idéfel kanske upptäcks först i förvaltningsfasen. Ett designfel kan resultera i ett misslyckat och bortkastat projekt även om alla har gjort ett perfekt arbete i projektets senare skeden.

Ett “perfekt genomfört” projekt kan också betraktas som misslyckat om det inte genererar verksamhetsnytta. Har bakomliggande idé varit dåligt genomarbetad kommer projektet inte att generera förväntad nytta.

Det gäller alltså att så snabbt som möjligt fånga resultatet av de tankefel som de inblandade orsakar och övriga risker som föreligger så att bra beslut kan tas löpande i projekten. För att göra detta behövs bättre metoder för kvalitetssäkring av projektens tidiga faser.

Kvalitetssäkrar man inte alla projektsteg med korta loopar kan “otur när man tänker” bli dyrt.