Målbilde eller målvei?

Uten å bli for filosofisk – er det målet eller veien som egentlig er målet? Jeg snakker ofte med virksomheter som er opptatt av å lage målbilder og målarkitekturer. Å sette seg mål å jobbe mot er jo fornuftig, men problemet kommer når en tror at en kan definere en endelig løsning og være i mål.

Kravspesifikasjoner og tidlig utvikling i et Business Analytics-prosjekt er som regel preget av funksjonalitet i produkter og hva løsningen skal inneholde av rapporter og analyser. Når løsningen når et visst modenhetsnivå og de initielle behovene mer eller mindre er dekket, ser vi stadig oftere at volumet på nye forespørsler fra forretningssiden øker til et nivå en ikke hadde forutsett og som en ikke klarer å holde tritt med. Grunnen til dette er naturligvis at Business Analytics-løsningen har bevist sin posisjon som verdidriver i viktige prosesser, og virksomheten begynner å se større og større potensial.

Paradoksalt nok ser vi som sagt at nye løsninger får en overraskende lang ledetid, noe som i stor grad påvirker forretningsverdien av løsningen. Sagt på en enkel måte – hvordan skal vi få ned tiden fra initiativ på forretningssiden til produksjonssatt løsning? Jeg tror, som tittelen på artikkelen antyder, at et tidlig fokus på å tilrettelegge for kontinuerlige endringer, i stedet for å fokusere relativt blindt på målbilder, vil bidra til å løse dette.

Først og fremst er det viktig å ha en organisasjon og en strategi for prioritering av forretningskrav, så en er sikker på at det som faktisk er viktigst blir utviklet først. Dernest må en tilrettelegge for at mye av behovene kan løses uten utviklingsprosjekter. Dette gjøres ved at brukerne selv settes i stand til å utvikle eller tilpasse løsninger, enten ved hjelp av funksjoner i verktøy som for eksempel bruk av Infomaps i Web Report Studio 9.2 eller Enterprise Guide, eller gjennom arkitekturgrep som å opprette prototypingsmuligheter eller ”sandkasser” for brukere.

Veldig mye kan ofte gjøres på teknisk arkitektur, og med SAS 9.2 er det nå mulig å automatisere mange prosesser som tidligere var manuelle, f.eks migrering av kode mellom miljøer. Manuelle prosesser bør så langt det er mulig elimineres – de er tidkrevende og en vesentlig kilde til feil. I SAS jobber vi nå med mange spennende prosjekter for automatisering og forenkling av løsningsadministrasjon.

Løsningsarkitektur og prosjektstrategi bør også være gjenstand for vurdering. I tradisjonelle Business Intelligence-løsninger er det for eksempel ekstrem fokus på kontroll og å utvikle for gjenbruk, spesielt i datavarehuset. Men er vi sikre på at dette er riktig hvis kravene og målet dreier seg mer mot rask utvikling? Eller kan det tenkes at en bør dele inn løsningen i flere lag med ulike nivåer av kvalitet, kontroll og styring? Konsern-KPI’er bør åpenbart være gjenstand for sterk kontroll, men jeg mener at i visse deler av en Business Analytics-løsning blir det feil å stille samme krav til alle data. Det tar for lang tid og gir liten verdi.

En kort artikkel er neppe stedet for en uttømmende beskrivelse av hvordan en kan redusere ”Time-to-market” for en Business Analytics-løsning. Som illustrert her kan en imidlertid møte dette ved allerede fra starten av utvikle prinsipper og arkitekturer for rask produksjonssetting og kontinuerlig endring – kort sagt ikke ha som mål å lage noe ferdig, men lage en løsning der veien blir målet.

Av Henrik Slettene, Senior Advisor

tags: analytics, business analytics, løsningsarkitektur

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <p> <pre lang="" line="" escaped=""> <q cite=""> <strike> <strong>