AO är en fallstudie – funktionsanalys av, hur någon använder en produkt innan den finns. I abstrakta scenarier beskrivs ”hur Aktören samspelar med en tänkt produkt kallad Goack, så att resultatet blir något av värde för Aktören”, med en speciell syntax. Aktören kan vara en fysisk person eller ett system. Medan namnet Goack är valt för att inte ge några associationer.
Scenarierna består av ett centralt händelseflöde, med eventuella villkor och loopar, som kallas ”Normalfall”. Scenarierna kan dessutom ha alternativa flöden som: ”Undantag” och ”Utvidgning”, samt ”Använder sig av” med hänvisning till ett annat scenario, som till en detaljritning eller subrutin. Det finns alltså strukturella likheter med både konstruktionsritningar och dataprogram
I första momentet beskrivs på övergripande nivå (Black box perspektiv) vad Goack utför på begäran av Aktören, utan att berätta eller ens bry sig om hur det går till. I nästa moment kompletteras beskrivningen med förtydligande av samma saker (White box perspektiv). Och slutligen sammanställs vad Goack utfört i de olika scenarierna till en funktionsbeskrivning av Goack, som tillsammans med scenarierna utgör en produktidé.
I ett tredje moment omvandlas de abstrakta scenarierna till konkreta scenarier som beskriver hur samspelat Aktör – Goacks fysiska motsvarighet blir med vald teknik, alltså hur någon använder den färdiga produkten.
Eftersom produktidén är implementationsoberoende, så kan Goack realiseras på ett eller fler olika sätt, inklusive som tjänsteprodukt. För att förstå principen så kan du föreställa dig att Aktören är handikappad och delegerar allt vad Aktören själv inte vill, inte vågar eller inte kan göra till Goack. Eller genom att du först beskriver vad Aktören själv gör, och sedan hur Aktören delegerar samma saker till Goack.
Metoden är bevisligen skalbar och kan användas för framtagning av helt nya industriprodukter, datasystem och tjänster, eller för omkonstruktioner. Som exempel på det senare, har jag jämfört en befintlig produkt med ett AO -alternativ. Utgångspunkten var syftet med en svensk innovation (maskin), som närmast har dominerat sin marknad ”ww”, och som jag är mycket väl förtrogen med. Med hjälp av AO tog jag fram en konceptuell beskrivning – ny produktidé.
Jag tillstår gärna att det var svårt, och att det krävde flera omtag, när jag halkade in på konstruktionsdetaljer. Men till slut blev resultatet så neutralt att det både kunde användas som underlag för en maskin, ett datasystem (exempelvis för simulering) eller en kombination av båda. Men det mest slående var skillnaden till originalet. Det senare reste så starka tvivel om kvalitén i min analys, att jag konsulterade flera sakkunniga för att få saken validerad. Med deras godkännande i ryggen började jag undersöka skillnaden och kom i stort sett fram till liknelserna A (före) och B (efter AO), som jag tidigare skrivit om.
Resultat av AO har några karaktäriska drag som jag delvis återupprepar. De innehåller färre kompromisser beroende på att alla funktioner (jämför pusselbitar) finns på plats innan realiseringen börjar. Eftersom konceptet är neutralt och kan utformas med senaste teknik, så är det sannolikt långlivat. Men verkar dessutom vara flexibelt och rustat att möta krav som inte tidigare var kända. Sist, men definitivt inte minst, så blir resultaten mer ändamålsenliga och slimmade, eftersom de endast innehåller kvalificerade funktioner som är spårbara till ”värdeskapande” scenarier och inte ad hoc ”bra att ha”.
Bland nackdelar har jag redan nämnt att principen uppfattas som en omväg och ”flummig” av många, i synnerhet fackmän, medan uppfinnare dessutom tycker att de klarar sig utan. Ingen tycks inse att det handlar om en mental hävstång, som kan lyfta tankarna till oanade höjder. För att göra metoden full rättvisa krävs främst personer med en viss fallenhet för abstraktioner. Själv har jag egen erfarenhet av hur lätt det är att hemfalla åt utvecklingsmodell typ A, fast att jag vet att det är fel. Och IBM uttalade en gång att det skulle krävas en hel ny generation, utan erfarenhetsmässig belastning, för att tillgodogöra sig den ursprungliga tekniken för datasystem. Men du behöver bara vänta till nästa avsnitt.
Författad av Conny Ohlsson.
Har du synpunkter, mejla gärna mig på [email protected]
