Sammanfattning

RefARK IoT kan användas för anskaffning via upphandling. RefARK IoT tillhandahåller en delmängd av de krav som en organisation behöver ställa vi anskaffning av IoT-system. Organisationen behöver hämta in egna krav och kombinera dessa med RefARK IoT:s krav kring IoT-system. Bereoende på speciella krav krav kring just de tillämpningar som IoT-systemet ska stödja kan det även tillkomma ytterligare krav som inte RefARK IoT tillhandahåller.

Olika organisationer kommer anskaffa IoT-system på olika sätt beroende på egna förutsättnignar och möjligheter. För att stödja detta är kraven i RefARK IoT framtagna som BÖR krav där en leverantörs förmåga ska kunna utvärderas. I detta avsnitt finns därför:

• exempel på hur RefARK IoT:s principer och krav kan användas för att utvärdera olika leverantörers lösningar för att bedöma den mest lämpade lösningen, tex genom att använda principer för att hitta ekomoniskt mest fördelaktiga anbud utifrån bästa förhållande mellan pris och kvalitet.

• exempel på hur en organisation kan omvandla BÖR kraven och deras utvärderingskriterier till SKA krav

RefARK IoT är inte ett färdigt stöd för upphandling men ger ett stöd för att ställa viktiga krav kring IoT-system och hur dessa kan utvärderas på ett bra sätt.

Att göra upphandling med stöd av RefARK IoT

Att göra en upphandling är något som arbetsgruppen för RefARK IoT inte har specialistkunnande kring, utan ger en vägledning hur principer och krav kan användas för att identifiera mest ekonomiskt fördelaktiga lösning utifrån kostnad och kvalitet. Där RefARK IoT:s principer och krav används för att bedöma kvaliteten på ett IoT-system.

OBS: Det material som tagits fram inom RefARK IoT kan inte obearbetat användas direkt i en upphandling.

OBS: Det förutsätts att den som ska göra en upphandling har den kunskap och erfarenhet som krävs för att faktiskt genomföra en upphandling.

OBS: Varje organisation behöver lägga till sin egen organisations specifika verksamhets- och IT-krav.

Open

RefARK IoT ger ett stöd för en del av den kravbild som bestälallaren behöver ta fram.

Grundprincipen för nyttjande av RefARK IoT vid upphandling

RefARK IoT ger en struktur där beställare kan utvärdera kravuppfyllnad, utifrån den beskrivning som en leverantör ger. Grundtanken är som i bilden nedan:

Open

Följande skulle kunna vara en arbetsprocess vid upphandling:

1. Beställaren fördelar en vikt mellan alla 10 principer, utgå tex ifrån 100%. Exempelmaterial kring hur beställare kan tänka kring detta finns här. Viktfördelningen bör vara tydlig och transparant redan vid utlysningen.

2. Beställaren går igenom kraven och utför följande:

   1. Beslutar vilka krav som är relevanta för sin organisation, varje krav ges ett visst antal maximum poäng. Maximum poängen summeras per princip, utifrån “Bidrar till Princip” kolumnen i kravlistan.

   2. Lägger till de krav som är specifika för den egna organisationen. Det kan vara både verksamhets- och IT-krav.

   3. Beställaren definierar hur utvärdering av lämnad beskrivning kommer göras. Detta kan tex ske utifrån en poängskala 1-5, där:

      1. 1 = “Lösningsbeskrivningen ger mycket otydlig beskrivning av tänkt lösning och/eller mycket låga mervärden för beställaren.”

      2. 2 = “Lösningsbeskrivningen ger otydlig beskrivning av tänkt lösning och/eller låga mervärden för beställaren.”

      3. 3 = “Lösningsbeskrivningen ger acceptabel beskrivning av tänkt lösning och/eller vissa mervärden för beställaren.”

      4. 4 = “Lösningsbeskrivningen ger tydlig beskrivning av tänkt lösning och/eller bra mervärden för beställaren.”

      5. 5 = “Lösningsbeskrivningen ger mycket tydlig beskrivning av tänkt lösning och/eller mycket bra mervärden för beställaren.”

   4. Tänk på i upphandlingsunderlaget att beskriva med exempel hur en leverantör kan ge “mycket tydlig” beskrivning och “bra mervärden”. Det kan vara tex att

      1. “mycket tydlig beskrivning” inkluderar samtliga utvärderingspunkter i respektive krav

      2. “mycket bra mervärden” tydligt anger hur leverans av kravet inkluderas i lösningen. Ange här hur leverantören kan få denna bedömning genom att tydligt beskriva vad som ingår i lösningen, vad som är tillägg och vad som kräver handpåläggning etc.

3. Beställaren går igenom vilka “ska” krav behöver tas fram för lösningen. RefARK IoT ger enbart stöd för bedömning av en leverantörs lösning. Utvärderingskriterierna på respektive krav kan vara en utgångspunkt kring vilka krav som beställaren behöver omvandla till “ska” krav.

4. Vid själva utvärderingen av lösningen kan det vara bra att ha en eller flera personer/arbetsgrupper som gör utvärderingen, tänk då på att dokumentera varje enskild bedömning, men även att beskriva i upphandlingsunderlaget hur bedömningen kommer gå till, tex medeltal av x personers bedömning eller konsensus från en gruppdiskussion. Detta för att skapa en tydlig transparans i arbetet och att om någon leverantör överklagar så finns tydligt och objektivt beskrivit hur bedömningen gått tillväga.

Avtal vid upphandling med RefARK IoT

Beställaren behöver ta fram fram lämpliga avtal för upphandlingen. Tänk då på att avtalet behöver hantera avtaletsperiodens alla faser, implementationsfasen, förvaltningsfasen och avslutningsfasen. Ofta är det olika konstruktion på avtal för projekt, förvaltning och konsulttimmar, avtalet behöver hantera alla dessa aspekter. För IoT-system kan det krävas en större flexibilitet i avtalssituationen då det ofta är flera leverantörer i hela IoT-systemet. Det är bra praxis att avtalstexten skickas ut tillsammans med upphandlingsunderlagen.

Något RefARK IoT arbetsgrupp förespråkar är att i avtal och upphandlingstexter notera att de svar på olika frågor som leverantör gett i sitt anbud bör bli en del av avtalet. Det ger tex en möjlighet att om leverantör i beskrivning anger att någon komponent ingår eller fungerar på visst sätt, så ska det bli en del av leverantörens leverans och därmed avtalet.

RefARK IoT i funktionsupphandling

Vid funktionsupphandling med hjälp av IoT behöver beställaren följa stegen 1-4 ovan. Beställaren behöver även besluta förhållandet mellan pris respektive kvalitetskrav. Tänk på att “ska” krav kan inte utvärderas. Vidare behöver beställaren ta fram fram lämpliga avtal för upphandlingen.

RefARK IoT vid förhandlat förfarande

Vid förhandlat förfarande kan RefARK IoT användas som underlag för förhandlingen, dvs leverantör ska i de förhandlingar som görs beskriva sin lösning och då detaljera hur den fungerar.

Hur byggs bra upphandlingskrav ?

Hur ett bra upphandlingskrav beror väldigt mycket på vilken upphandlingsform som väljs för aktuell upphandling.

Ett bra krav uppfyller tex följande:

• Det är tydligt vad leverantören ska leverera, och på vilket sätt

• Det är tydligt hur beställaren kan/kommer verifiera att leverans skett

• Det är tydligt vem ska kunna utföra den funktion som avses

• Beställaren får en tydlig bild av vad och hur leverantören kommer att leverera

Exempel på hur RefARK IoT:s krav kan omformuleras till SKA krav

Alla exempl krav har skapats genom att kombinera informationen i kravtexten med utvärderingskriterierna i fältet “Utvärdera utifrån”. För flera av fallen gör detta att antalet krav blir lika många eller fler än utvärderingskriterierna.

Exempel på SKA krav baserade på KIOT-005:

Kravet handlar om beställarens möjlighet att redigera regler i IoT-systemet som resulterar i händelser.

User Stories

• Som IoT-administratör i IoT-systemet ska jag kunna skapa nya och/eller redigera befintliga händelser utifrån inkommande data och/eller lagrade data för att tillgodose olika tillämpningars behov

  • Acceptanskriterie: En händelse ska kunna generas om inkommande data ligger utanför ett tröskelvärde, statistisk analys av flera inkommande data eller om ändringar är för stora/små över en specificerad tidsperiod.

  • Acceptanskriterie: Redigering av av händelser ska ske i ett webbgränssnitt där de flesta ändringar utförs utan att programkod behöver skrivas

Som funktionellt respektive icke funktionellt krav

• IoT-adminstratör SKA i ett webbgränssnitt och utan programmeringskunskaper kunna skapa nya och redigera befinliga händelsevillkor utifrån inkommande data och/eller lagrad data.

• En händelse SKA kunna utlösas baserat på tröskelvärden, statiska analyser av flera inkommande värden och/eller om ändringar i inkommande värde är för stora/små över en valfri tidsperiod.

Exempel på SKA krav baserade på KIOT-008

Kravet handlar om hur versionshantering går till.

Som icke funktionella krav

• Dokumentation till IoT-systemet SKA ge en beskrivning av hur bakåtkompatibiltet mellan ingående moduler upprätthålls

• Dokumentation till IoT-systemet SKA ge en beskrivning av hur versionshantering av ingående moduler görs, ex uppdragering av databasssystem.

• Dokumentationen till IoT-systemet SKA ge en beskrivning av hur versionshantering av gränssnitt för dataöverföring.

• Dokumentationen till IoT-systmet SKA ge en beskrivning av versionshanteringen av IoT-systemets arkitektur som helhet.

• Dokumentation till IoT-systemet SKA ge en beskrivning av hur livscykelhantering av API görs och på vilket sätt IoT-systemets API:er datamodeller beräknas vara bakåtkompatibla.

• Leverantören SKA XX [dagar/månader] i förväg informera om ändringar i API och datamodeller, där det framgår vad som förändras.

Exempel på SKA krav baserade på KIOT-028

Kravet handlar om hur en fysisk IoT-enhet ska kunna bytas men fortsatt kopplas till samma IoT-enhet

Som User story

• som administratör av IoT-system SKA jag i ett webbgränssnitt utan programmeringskunskap kunna byta ut en fysisk IoT-enhet till en annan och bibehålla den virtuella IoT-enheten som alla tillämpningar interagerar med.

Som funktionellt krav

• En fysisk IoT-enhet ska kunna ersättas av en ny som kan kopplas till samma IoT-enhet som tidigare IoT-enhet utan påverkan på den virtuella IoT-enheten.