Fremgangsmåte: Kjøp av programvare

Avdekke behov

Organisasjonen må snakke sammen på tvers av faggrensene for å avdekke hva den virkelig har behov for samtidig som relevante problemstillinger også må diskuteres.

Denne påminnelsen kommer fra Thomas Brørs, vice president i Platon AS, som er Nordens største konsulentselskap på dette området.

- Ingen tjener på at folk i organisasjonen sitter på hver sin tue og kun definerer sitt behov isolert sett. Likevel er det dessverre ofte tilfellet, sier Brørs.

Han advarer også mot at mange bedriftsinnkjøpere tar kjøpsbeslutninger på grunnlag av god kjemi med en eller flere selgere, og det faktisk ofte etter bare et møte.

Tilleggskostnader

- Kartlegg det totale kostnadsbildet. Vær svært bevisst på at kostnader ved kjøp av software ikke bare er knyttet opp mot selve innkjøpsprisen/lisenskostnadene, men i like stor grad opp mot tilleggskostnadene, sier Brørs.

Thomas Brørs trekker spesielt fram følgende kostnader:

• Årlig servicegebyr til leverandør.
• Implementering av selve verktøyet.
• Eventuelle organisasjons- eller prosessendringer som vil være påkrevet eller ønskelig ved innføring av nytt støtteverktøy.
• Funksjonell endringshåndtering.
• Drifting av applikasjonen og den påvirkning en ny applikasjon måtte ha på eksisterende infrastruktur.
• Andre og mer uspesifiserte kostnader som kan påløpe.

Menneskelig faktor

Brørs minner også om den menneskelige faktor. Ledelsen må være bevisst på hva konsekvensen blir for den enkelte medarbeider. Han og hun skal lære seg et helt nytt støttesystem. Still følgende spørsmål:

• Hvordan skal innføringen av nytt system gjennomføres?
• Hva blir kostnaden?
• Hva med opplæring og kostnadene rundt dette?
• Hva er poenget med anskaffelse og opplæring dersom det nye verktøyet viser seg å ikke ha tilfredsstillende støtte for de forretningsprosesser som er gjeldende for organisasjonen?

Konsekvenser

- Konsekvensene ved feil investering kan bli meget alvorlige, fastslår Brørs. I verste fall kan bedriften få et verktøy som organisasjonen kun gjør et mer eller mindre halvhjertet forsøk på å implementere. Resultatet er et verktøy og et system som tilnærmet ingen benytter fordi de må fortsette å forholde seg til de eksisterende (gamle). Den viktigste årsaken til dette faktum er at det nye verktøyet ikke oppfyller alle nødvendige forretningsmessige krav som burde ha ligget til grunn for anskaffelsene.

Selvfølgelig blir den enkleste løsningen å heller benytte det gode gamle verktøyet som man tross alt vet hvordan fungerer og som, på et vis, fortsatt klarer å utføre de oppgavene man skal ha gjort. Det nye systemet og verktøyet blir liggende uvirksomt, et system som skulle ha gitt bedriften og organisasjonen langt mer riktig og oppdatert informasjon. Konsekvensen kan lett bli store økonomisk tap, mener Thomas Brørs.

Grunnleggende spørsmål

- Faktisk handler det ikke om annet enn å være bevisst og villig til å investere noen få kroner og ressurser før en tar den endelige beslutningen, sier Brørs. Han fastslår at nyttige stikkord for slikt forarbeid er:

• Forretningsmessige behov.
• Tekniske krav.
• Organisatoriske konsekvenser for øvrig.

Det første spørsmålet man alltid bør stille, er det grunnleggende spørsmålet om bedriften og organisasjonen virkelig har et behov for nytt støtteverktøy. Først når svaret er et klart ja, kan en gå videre i prosessen.

Samtidig kan det være en stor fordel at en gjør en seriøs vurdering av om organisasjonen virkelig har behov for å effektivisere forretningsprosessene. Hvis ja, bør disse prosessene være styrende selv om man også tar hensyn til de andre behovene.

Forankring

Bruk nødvendig tid. Stegene bedriften bør gå er hver for seg relativt enkle. Utfordringen ligger i å skape en bred forankring internt i organisasjonen, ikke minst hos ansvarlige ledere både på forretnings- og it-siden. Forankringen skapes ved å la medarbeiderne involveres i prosessen fra start. En prosess som enkelt kan oppsummeres i følgende punkter:

• Finn ut av det grunnleggende behovet - har vi bruk for et nytt verktøy?
• Utarbeid et målbilde for hva din organisasjon ønsker å oppnå ved hjelp av et nytt verktøy, både i dag og på sikt.
• Strukturer kravene, både forretningsmessige krav og it-krav. Balanser kravene mellom forretning, it og andre organisasjonsrelevante momenter i arbeidet med kravspesifikasjonen. Grader kravene etter viktighet.
• Formuler også kravene på en slik måte at ikke alle leverandører kan svare ja på de fleste krav. Grader svarene, gjerne på en definert skala. Unngå å innby til rene ja-/nei-svar. Dette punktet er kanskje det mest utfordrende når bedriften skal skrive en god kravspesifikasjon.
• Kartlegg leverandørmarkedet.

Leverandørene

La utvalgte leverandører respondere ut fra dine krav, og ikke ut fra sine egne standardiserte salgspresentasjoner, råder Brørs. Slike presentasjoner er som regel alltid veldig fristende og gode. Presenter kravene dine både ved hjelp av en kravspesifikasjon og ved konkrete demonstrasjoner for en større gruppe i din organisasjon.

Evaluer responsen

Inkluder kost/nytte-vurderinger og eventuell forventet påvirkning på fremtidig inntjening.

Brørs minner om at det grunnleggende er å være strukturert og gjennomføre en oversiktlig prosess. I tillegg er det enkelte punkter man må ta med seg. De viktigste er:

• Gjør eventuelle prosess­endringer før bedriften implementerer noe nytt - ellers vil man ikke klare å hente ut like stor gevinst. I tillegg vil et eventuelt endringsarbeid på et senere tidspunkt både bli tyngre og mer kostbart fordi en også kanskje må endre måten et eventuelt verktøy er implementert på.
• Involver alle relevante parter for å skape bred forankring og for å fange opp alle relevante behov.n