.png){kind=logo}
Skal du anskaffe et nytt SD-anlegg eller toppsystem, er kravspesifikasjonen avgjørende for hvilken løsning du ender opp med. Kravene påvirker blant annet hvilke leverandører som kan konkurrere, hvor enkelt systemet kan integreres med eksisterende anlegg, og hvor fleksibelt det blir å drifte og videreutvikle senere.
Denne artikkelen er skrevet for byggeiere som skal anskaffe eller oppgradere SD-anlegg eller toppsystem, og for rådgivere som utarbeider kravspesifikasjoner og konkurransegrunnlag.
Her er fire områder vi mener bør vurderes spesielt nøye før kravene låses:
1. Åpne standarder
For å redusere leverandøravhengighet bør kravspesifikasjonen beskrive hvilke åpne eller standardiserte protokoller og grensesnitt løsningen skal støtte. BACnet, KNX, Modbus, MQTT og OPC UA er eksempler på teknologier som kan gjøre det mulig å koble sammen utstyr og systemer fra ulike leverandører.
Det er samtidig ikke nok å bare skrive at en bestemt protokoll skal støttes. Still også krav til at integrasjonene er dokumenterte og tilgjengelige, slik at utstyr kan byttes, systemet kan bygges ut og nye leverandører kan kobles på senere. Målet bør være at kunden beholder kontrollen over anlegget og ikke blir låst til én leverandør.
2. Hva er egentlig «nice-to-have»?
Det er lett å fylle en kravspesifikasjon med detaljerte «skal»-krav til funksjoner, oppsett og brukergrensesnitt. Problemet er at hvert absolutte krav snevrer inn hvilke løsninger som kan tilbys.
Skill derfor mellom det som faktisk er nødvendig for å dekke behovet, og det som bare er ønskelig. Kritiske krav kan være «skal»-krav, mens funksjoner som gir merverdi heller kan beskrives som «bør»-krav eller vurderes som en del av tildelingskriteriene.
Der det er mulig, bør kravene beskrive hva løsningen skal oppnå, fremfor nøyaktig hvordan den skal bygges. Det gir leverandørene større rom til å tilby gode løsninger og reduserer risikoen for at konkurransen begrenses av detaljer som egentlig ikke er avgjørende.
3. Skybasert eller lokal installasjon?
Valget mellom skybasert og lokal installasjon bør tas ut fra behov, sikkerhetskrav og hvordan løsningen skal driftes over tid.
En skybasert løsning gjør det normalt enklere å rulle ut oppdateringer fortløpende, administrere systemet sentralt og gi tilgang uavhengig av hvor brukeren befinner seg. En lokal installasjon kan på sin side være riktig der nettverk, sikkerhetskrav eller andre forhold gjør at systemet må driftes innenfor kundens egen infrastruktur.
Sikkerhet avgjøres ikke av om løsningen står lokalt eller i skyen alene. Begge alternativer krever blant annet tilgangsstyring, oppdateringer, overvåking og gode rutiner. NSM peker også på at skytjenester kan gi god sikkerhet, men at virksomheten må vurdere risikoen og avklare ansvarsdelingen med leverandøren.
Ved anskaffelsen bør man derfor vurdere hele levetiden til løsningen: etablering, drift, sikkerhetsoppdateringer, backup, vedlikehold og fremtidige oppgraderinger – ikke bare investeringen den dagen systemet settes i drift.
Evolo kan leveres både skybasert og lokalt. For de fleste av våre kunder er sky den naturlige løsningen, mens lokal installasjon brukes der kundens krav tilsier det.
4. Pris- og distribusjonsmodell
Pris bør vurderes over hele levetiden til løsningen, ikke bare ut fra etableringskostnaden. Be derfor om et tydelig kostnadsbilde som viser hva som inngår i lisensen, hvordan prisen påvirkes når anlegget utvides, og hva som eventuelt faktureres separat.
Sjekk blant annet hvordan leverandøren priser datapunkter, brukere, visninger, funksjoner, integrasjoner, oppgraderinger og support. En modell som virker rimelig ved oppstart kan bli kostbar dersom nye bygg, brukere eller funksjoner utløser store tillegg senere.
Evolo følger en lisensmodell der kostnaden baseres på antall datapunkter, mens brukere, alarmer, visninger og funksjoner ikke prises som egne moduler. Det gjør det enklere å se hvordan kostnaden utvikler seg når løsningen bygges ut.
Frihet til å velge installatør
Leverandøravhengighet handler ikke bare om tekniske protokoller. Det handler også om hvem som faktisk kan gjøre endringer, utvidelser og service på anlegget etter at det er satt i drift.
Kravspesifikasjonen bør derfor avklare hvem som skal ha tilgang til systemet, hvordan nye leverandører kan kobles på, og om kunden står fritt til å velge installatør ved senere utvidelser eller servicearbeid.
Evolo bruker en partnermodell der fysisk installasjon, integrasjon og service utføres av godkjente Evolo-partnere, mens Evolo utvikler og drifter programvaren. Kunden kan dermed velge mellom flere partnere også etter at anlegget er satt i drift.
Det gir mindre leverandøravhengighet og gjør det enklere å opprettholde konkurranse på installasjon og service over tid.
Når teknologien går videre, bør systemet gjøre det samme
En anskaffelse bør ikke bare løse dagens behov, men også gi rom for endringer senere. Nye bygg, nye integrasjoner, nye krav og ny teknologi kommer uansett over tid.
Åpne standarder, tydelige roller og frihet til å velge leverandører gjør det enklere å videreutvikle løsningen uten å starte på nytt. Et godt toppsystem bør derfor være enkelt å eie, drifte og bygge videre på gjennom hele levetiden.
En god anskaffelse handler derfor ikke bare om hvilke funksjoner toppsystemet har ved oppstart. Like viktig er hvor enkelt løsningen kan integreres, videreutvikles og konkurranseutsettes gjennom hele levetiden.
Gode krav til åpne standarder, prismodell, installatørvalg og fremtidige oppgraderinger gir større frihet – og reduserer risikoen for kostbar leverandøravhengighet senere.
