Ved anbud av IT-tjenester blir ofte mange prosjekter alt for dyre og gir ikke ønsket effekt og innovasjon for organisasjonen som står bak utlysningen. Her må utlyser ta ansvar allerede ved skriving av utlysningsteksten og kravspesifikasjonene i anbudet. En god grunnregel for de som definerer IT-tjenester og produkter er å begrense HVORFOR, NÅR og HVA, men la leverandøren stå fritt til å definere HVORDAN. En velskrevet kravspesifikasjon er halvveis til et vellykket prosjekt.

Mange programvareutlysninger eller spesifikasjoner for "tilpasningsprosjekter", er sterkt fokusert på teknologi og ressurser. For eksempel forpliktelsen til å være på JAVA-språket, med et team på minimum 50 programmerere, i 3 år. De glemmer imidlertid skjulte kostnader som enkelte leverandører med vilje eller utilsiktet utelater i sine forslag.

Hensikten med dette blogginnlegget er å peke på noen av disse kostnadene, og utfordre de som har ansvar for å definere utviklings- og implementeringskrav, til å unngå eller minimere risikoen i sine anskaffelsesprosesser. Målet er å skape mer VERDI for kunden ved å åpne døren for leverandører og prosjekter, inspirert av innovative metoder som f.eks. DevOps, Lean IT eller Hyper smidig/ SCRUM. Ifølge en artikkel iFinancial Times, kan noen av disse tilnærmingene være tre ganger raskere og med høyere suksessrate enn tradisjonell utvikling.

1. Hurtig prototyping

Leverandøren bør kunne presentere en funksjonell prototype innen kort tid. Denne skal vise de grunnleggende tekniske egenskapene (brukere, påloggingsprosess, menyer, poster, tabeller, rapporter osv.) og den grunnleggende grafiske layouten.

Tidsrammen for utarbeidelse av prototype bør kvantifiseres av leverandøren slik at kunden har en ide om effektiviteten til utviklingsprosessen.

Rask prototyping kan til og med bidra i anskaffelsesfasen, til å vurdere utviklingseffektiviteten blant interesserte leverandører. Til slutt kan kunden vurdere verdien av en belønning eller en utbetalingssum for utarbeidelsen av et proof of concept, til en eller flere deltakere i konkurransen.

2. Kildekode

Løsningsleverandøren bør etter hvert bli pålagt å levere kildekoden på et standardspråk, klar til å bli kompilert fritt, og uavhengig av hvem som har laget koden. C ++, C # eller JAVA vil være de mest brukte alternativene. Dette vil gi kunden fordelen av leverandøruavhengighet (selv om de ikke bruker den) og autonomi i den fremtidige utviklingen av løsningen.

Leverandøren bør kunne prissette kildekoden til løsningen som skal leveres. Noen ganger kan kildekoden leveres, men for astronomiske verdier eller, om ikke standard, avhengig av lisensiering av en kostbar plattform.

Kildekoden bør alltid være ordentlig dokumentert for å minimere kostnadene ved bruk av andre programmerere i fremtiden.

Om det ikke er mulig å levere kildekoden (da det er en produkt/markedspakke) skal leverandøren som kompensasjon gi andre garantier. For eksempel prisen for ubegrenset levetid av lisensieringen.

3. Ubegrenset lisensiering

Mange organisasjoner begynner å bruke en gitt programvare med et gitt antall brukere, og plutselig, på grunn av en eller annen lovgivningsendring, fusjon eller tilknytning til andre enheter eller av en annen beredskap i deres økosystem, blir de tvunget til raskt å øke antallet brukere. Vanlig lisensiering per bruker, per CPU eller per server kan begrense tid og kostnader eller til og med blokkere disse endringene av budsjettmessige årsaker. I statlige institusjoner kunne man for eksempel bli stanset i ett år, frem til godkjenning av nytt årsbudsjett og hele den administrative prosessen med kjøpsprosessen. Derfor bør programvareleverandører i sine forslag kunne presentere kostnadene ved lisensiering for et ubegrenset antall brukere.

4. Livstidslisensiering

Det samme gjelder for tidsmessig lisensiering. Mange programvareleverandører fakturerer lisensiering på årsbasis. Med argumentet om teknologisk oppdatering belaster de kunden en fast årlig kostnad. Hvis kunden av en eller annen grunn ikke lenger ønsker å betale årslisensen, for eksempel for et regnskapssystem som skal avvikles men trenger å holde styr på de historiske registreringene, vil kunden være i en vanskelig situasjon. I slike tilfeller bør programvareleverandører i sine forslag kunne presentere kostnadene ved livstidslisensiering av sine løsninger (med eller uten valgfri støtte og vedlikeholdstjeneste).

5. Teknologisk immunitet

Hvis en løsning laget i en gitt teknologi må utvikles til en ny teknologi, hva er tiden og kostnaden for en slik operasjon? Hva er den teknologiske avhengigheten eller immuniteten til denne løsningen? Programvareleverandører bør avklare i sine forslag:

• om løsningen ble manuelt programmert og all regellogikk er innebygd i koden (på et gitt språk og teknologi);
• om den ble automatisk generert fra en mal der regelsettene er lagret;
• om den fungerer på en standard nettleser eller trenger å installere en proprietær applikasjon på hver arbeidsstasjon.
• hva er de typiske tidsrammene og kostnadene ved teknologisk endring av løsningen, med historiske eksempler.

6. Endre effektivitet og evolusjonært vedlikehold

Ifølge en studie av Barry Bohem anslås det at i programvare utviklingsprosesser basert på Vannfall modellen  at kostnaden for en endring i driftsfasen av systemet er 150 ganger kostnaden for en endring i kravfasen. Derfor bør leverandørene i sine forslag kunne presentere kostnadsforholdet til endringer i de ulike designfasene slik at kunden kan ta kontroll over prosjektkostnadene og ikke holdes som gissel for en raskt utdatert prosjektspesifikasjon over tid.

Etter prosjektavslutning og levering oppstår det samme spørsmålet om prisen på løpende vedlikehold. Hva er forholdet mellom prisen på funksjonsendringer når systemet er i drift versus prisen på å endre de innledende krav i anbudsutlysningen?

Hvis dette forholdet er vanskelig å måle, bør en effektiv beregning etterspørres, eller leverandører må bes om å gi spesifikke tid-/kostnadseksempler for nye funksjoner, som kan introduseres etter at systemet er implementert.

7. Programvaremodellering (Industry Inspiration 4.0)

I tilfelle programvareløsningen er utviklet fra modellering og automatisk generering, og derfor nyter godt av teknologisk immunitet (avsnitt 5.), bør kunden kunne videreutvikle løsningen senere på egen hånd. Kunden må kunne beholde malen (de forutsetninger/innstillinger som automatisk genererte applikasjonen). Derfor må leverandøren presentere bruks- og lisenskostnadene for modellerings- og automatisk generasjonsplattformen, samt modellkostnadene.

Leverandøren skal også kunne levere dokumentasjon om løsningens komplette arkitektur (datastruktur, relasjoner, regelsett og prosesser) og kostnadene ved dette.

8. Teknologioverføring

Leverandøren skal kunne presentere en teknologioverføringsplan for kunden. Denne bør inkludere opplæring i bruk av modellerings- og plattform for automatisk kodegenerering for å gi kunden den kunnskapen som er nødvendig for vedlikehold og videreutvikling, uavhengig av om denne tjenesten skal leveres senere av leverandøren.

9. Programvareutvidelse (Add-ins)

Løsningen som tilbys skal inneholde verktøy som gjør at kunden kan få tilgang til data for avansert spørring (lesing), visning gjennom Open Data Protocol (OData) og for integrasjon med andre systemer, inkludert indikatorgenerering og rapportering. For eksempel WebServices API som viser all funksjonaliteten til applikasjoner.

10. (Cyber) Sikkerhet

Løsningen som tilbys bør være i samsvar med den nyeste europeiske og nasjonale digitale sikkerhetslovgivning, i samsvar med GDPR og NIS, og det bør være enkelt å raskt tilpasse den fremtidige utviklinger av disse standardene.

Konklusjon

Artikkelen viser hva vi foreslår at du skal ha med og ikke ha med i en spesifikasjon for å utvikle eller "tilpasse" spesifikk administrasjonsprogramvare, fordi en god kravspesifikasjon er halve jobben av et vellykket prosjekt.

Søk inspirasjon fra pre-kommersielle anskaffelser av europeiske prosjekter som bidrar mye til innovative løsninger.

Selv ved renovering bør du vurdere å erstatte det du har installert med ny programvare, spesielt om det gir lavere lisensverdier. Offentlige anskaffelser krever i det minste å ta høyde for å sjekke ut mulighetene for en tilsvarende løsning.

Vi har omtalt 10 viktige kundefordeler ved kjøp av spesifikke programvareløsninger for administrasjon. De kan også tjene som en guide for drastisk å redusere noen av de skjulte kostnadene, som følge av gammeldagse utviklingsmetoder, som gir:

• Økt avhengighet av foreldet teknologi
• Økt avhengighet av mann/time-ressurser
• Økt avhengighet av en enkelt leverandør
• Langsom utvikling av nye funksjoner
• Ublu priser for vedlikehold og global evolusjonær tilpasning
• Uforutsette lisenser for nye brukere og tidsperioder