Hvordan få fri programvare inn i din virksomhet

Mange har sett utfordringene som oppstår ved at man gjerne ønsker at fri programvare skal benyttes, men ikke legger til rette for dette. Et godt eksempel er Sun's Simon Phipps som tar opp anskaffelsesprosesser.

Hvis jeg tillater meg å sitere fritt fra hukommelsen så forteller Phipps at dersom du bruker en anskaffelsesprosess rettet mot kjøp av lisenser, ja så vil du ende opp med (bombe) å kjøpe lisenser. Ingen av fordelene ved bred oppslutning ("adoption-led") og "det som faktisk fungerer" med fri programvare kan passe inn dersom en benytter disse prosessene. Fri programvare kommer inn i organisasjoner i to trinn, noe vi også har erfart gjennom våre mange oppdrag:

1. Fri programvare tas i bruk gjennom prototyping, piloter og ekte testing
   
2. Skalering, driftsoppsett, produksjonssetting kjøpes inn på lik linje med annen programvare (valgfritt)
   

Hvis man tenker nøye gjennom dette fenomenet (to-trinns prosessen) så ser man jo at det vesentlige med en inkluderende anskaffelsesprosess vil være å fasilitere dette første trinnet: det å faktisk prototype, kjøre piloter og kjøre reelle tester. Trolig er kostnadene forbundet med å kjøre en strukturert og gjennomarbeidet anskaffelsesprosess (kravinnsamling, omfang, kriterier, prekvalifisering, utsendelse av anbud, evaluering, oppfølging, konklusjon etc) langt høyere enn å kjøre to alternative løsninger mot hverandre i en kontrollert prototype, men dette kan jo variere fra selskap til selskap. La oss se litt på risikoen ved å benytte seg av slike ekskluderende anskaffelsesprosesser:

• Fri programvare har vanskelig for å passe inn i sammenlikningsmodellen (les: det kan finnes bedre løsninger som dere ikke har vurdert)
• Besvarelser, tilbud og evalueringer gjøres på et rent teoretisk grunnlag (les: bokstavkjeks og skryt vektlegges høyere enn objektive resultater)
• Samspillet og kompetansen hos produkt- og tjenesteleverandører er uprøvd i din kontekst (les: du påtar deg ansvaret for "betatesting" av samarbeidet)
• Implisitte forutsetninger kommer først til overflaten når avtaler er inngått (les: du har ingen forutsetning for å vite at tilbudet er fri for "bivirkninger")

Listen kunne vært lengre, men det er viktig å ikke problematisere for mye - dette skulle være tilstrekkelig til å få enhver som er opptatt av å redusere risiko til å sperre opp øynene. Løsningen på dette må jo være en alternativ anskaffelsesprosess som likner mer på dette:

1. Finn en representativ del av arkitekturen som kan benyttes som prototype for leverandører
2. Velg de reelle beslutningsdrivere dere faktisk kommer til å benytte som kriterie for å velge leverandør (nå snakker vi 2, 3, 4 drivere på høyt plan, ikke hvorvidt løsningen støtter en eller annen spesifikasjon)
3. Inviter to (evt fler avhengig av din økonomi) leverandører dere har tillit til til å komme og gjennomføre en kontrollert prototype (på begrenset tid) av arkitekturen, og betal dem for jobben. Det trenger ikke å være fullpris, men dere er jo interessert i å finne den beste løsningen - da må dere legge til rette for at dere sammenlikner på best mulig måte.
4. Be leverandørene om å presentere resultatet i slutten av perioden, og vurder dem med tanke på beslutningsdriverene
5. Krev at prototypen skal kunne overtas, testes og gjennomgås av dere selv i etterkant for å eventuelt etterprøve ting dere er usikre på
   

Med en slik fremgangsmåte vil langt mer reelle problemstillinger dukke opp, spørsmål blir mer objektivt besvart og samspillet demonstrert. Kanskje langt mer interessant er at dette er en risikoreduserende prosess, i motsetning til de prosesser som vanligvis benyttes for anskaffelser.

Bruk dette som et utgangspunkt til å endre hvordan dere ser på anskaffelse av IT - kostnaden forbundet med dette er enkel å regne på satt opp mot usikkerheten i en teoretisk og uprøvet besvarelse.

Tross alt: hvordan tør dere fortsette med den iboende risikoen dere har i dagens prosess?