Vägledning ÖTP 1 v2.0

Utfärdad Sven-Håkan Olsson Godkänd av Janne Dicander Dokumenttyp Vägledning ÖTP Status Fastställd Identitet Vägledn ÖTP Version Dokversion 1.0 Sid 1 (9) Versionsdatum 2007-09-19 Vägledning ÖTP 1 v2.0 1 ÖTP: Sambruks Öppen Teknisk Plattform Sambrplform_vagledn_OTP_v20.doc Projektledare ÖTP Janne Dicander janne.dicander@jonkoping.se Telefon: 036-10 53 06 Mobil & SMS: 070-623 53 06

Sambrplform_vagledn_OTP_v20.doc 2(9) Vägledning ÖTP Projektnamn ÖTP Ytterst projektbeställare (YPB) Janne Dicander Aktuell beslutspunkt Delegerad projektbeställare (DPB) Janne Dicander Författare/Projektledare Sven-Håkan Olsson Fastställd, datum 2007-09-19 Historik och beslutade ändringar: Datum Ändring Ändrad av 2007-04-20 Dokumentet etableras Sven-Håkan Olsson Dokumentversion 0.2, utgåva för Sven-Håkan Olsson 2007-05-07 synpunktsinhämtning 2007-09-19 Utgåva för ÖTP v2.0 Sven-Håkan Olsson Bilagor: Nr Beteckning Version Identitet -

Sambrplform_vagledn_OTP_v20.doc 3(9) Innehåll: 1. Inledning...4 2. Anskaffanden och kravtexter...4 2.1. Syften med kravtexter...4 2.1.1. Selektera bort leverantör...5 2.1.2. Betygsätta leverantör, kora vinnare...5 2.1.3. Att få lösningsförslag från leverantör, kora vinnare...5 2.1.4. Ge kravbild för ev skräddarsydd systemutveckling...6 2.1.5. Få in textmaterial för senare kontraktsskrivning...6 2.1.6. Samla på råmaterial till senare förhandling...6 2.1.7. Samla på råmaterial till senare stämning...7 2.1.8. Driva marknaden roadmap...7 3. Betygskriterier...8

Sambrplform_vagledn_OTP_v20.doc 4(9) 1. INLEDNING Detta dokument tänks vara en mycket kort vägledning för olika sätt som Öppen Teknisk Plattform ÖTP kan användas (för denna dokumentversion är det ÖTP V2.0 som refereras). Det mesta av vägledningskaraktär står dock i ÖTP-skriften i sig. Emellertid ska ÖTP vara lämpligt att spridas brett till många olika parter - leverantörer, kommuner, övrig offentlig sektor etc. Därför finns det behov av att i förevarande dokument samla vissa vägledningspunkter som mer är tänkta att läsas internt inom Sambruk och medlemskommunerna, framförallt i samband med anskaffanden. Sambruk planerar även att senare ge ut Kort om ÖTP vilket är tänkt att bli ett mer populärt hållet, översiktligt dokument för en bredare läsarskara, utan detaljerade teknikspecifikationer. Förhoppningsvis finns det en mycket god återanvändningspotential i olika anskaffandens icke-funktionella kravdokument, även sådana planeras tillgängliggöras inom Sambruk. 2. ANSKAFFANDEN OCH KRAVTEXTER 2.1. Syften med kravtexter Den allra största skillnaden mellan strukturen i ÖTP V2.0 och i föregångaren V1.2 är att nu inkluderas ett stort antal konkreta kravtexter som är tänkt att användas som palett att välja ur bl a i samband med anskaffanden. Anskaffandena kan vara av många slag varav upphandling är ett. Ingen verksamhetsnytta uppstår emellertid i ett anskaffande i sig - detta uppstår först när den anskaffade lösningen fungerar väl och ger intern effektivisering samt bättre medborgarservice, osv. Därför är det inte tänkt att man ska se strikt på alla kravtexter i ÖTP som bara direkt ämnade att rakt av användas i upphandlingsdokument, även om de allra flesta också ska fungera väl på det sättet. Istället är de beskrivande texterna och kravpunkterna framförallt tänkta att göra det möjligt att vara tydlig mot kommunernas leverantörer och att kontinuerligt hålla kravbilden verksamhetsnära, även långt efter en upphandling. En balans mellan upphandlingsformalia och verksamhetsnytta på sikt, måste alltså erhållas. Strukturen i kravtexterna är sådan att dessa är skrivna i ett format så att de lånar sig väl att användas t ex som antingen Skall- eller Bör-krav i ett icke-funktionellt kravdokument vilket skapas per anskaffande (se kapitlet Dokumentstruktur i ÖTP).

Sambrplform_vagledn_OTP_v20.doc 5(9) Följande är några exempel på användningsområden för kravpunkter hämtade från ÖTP. 2.1.1. Selektera bort leverantör Typiskt tillfälle: LOU 2 -upphandling, ramavtals-avrop, direktupphandling. Typisk kravsort: Skall-krav. Kommentar: Detta är naturligtvis en mycket vanlig användning av kravtexter. Skall-krav kan inte betygsättas utan följden blir att anbudet selekteras bort eller får vara kvar för vidare bedömning. Däremot kan det vara fråga om att verifiera att ett Skall-krav verkligen uppfylls, då använder man ofta en formulering med Beskriv tillsammans med Skall, beroende på upphandlingskultur. En nackdel är att upphandlaren måste göra en bedömning som kan vara vansklig att försvara i händelse av överprövning, varför man ibland har en motvilja mot att inkludera Beskriv i Skall-krav. Se dock nedanstående ytterligare användningar av Beskriv. 2.1.2. Betygsätta leverantör, kora vinnare Typiskt tillfälle: LOU-upphandling, ramavtals-avrop, direktupphandling. Typisk kravsort: Bör-, Beskriv-krav. Kommentar: Detta är förstås en annan mycket vanlig användning av kravtexter. Anbudsgivarens svar på Bör-krav ska bedömas och betygsättas så att en eller flera vinnare i upphandlingen sedan kan utses (efter att även pris vägts in). Av rättviseskäl och för att inte riskera problem i händelse av överprövning måste det gå att motivera varför ett visst betyg getts till ett visst anbuds-svar, se även avsnittet Betygskriterier. 2.1.3. Att få lösningsförslag från leverantör, kora vinnare Typiskt tillfälle: LOU-upphandling (särskilt vid förhandlad upphandling), ramavtals-avrop, direktupphandling, kravhantering vid öpen programvara. Typisk kravsort: Beskriv-krav. Kommentar: Här är tanken att man vänder på initiativet och istället för att detaljerat inom Sambruk/kommun tänka ut och specificera ett antal icke-funktionella krav, så ber man om lösningsförslag från leverantörer som anskaffaren sedan värderar mot varann. Flera fördelar finns med detta, i viss mån får leverantören bekosta analys istället för att anskaffaren ska behöva göra det, dels finns det ofta ett problem med detaljerat beskrivna krav (som man vet skulle fungera bra) att en annan variant som är något annorlunda faktiskt skulle kunna fungera precis lika bra, och där kanske kostnaden kan bli lägre. Nackdelen är att det krävs stor kunskap för att kunna väga förslagen mot varann och betygssätta dem. Det kan också behövas dialog för att förstå hur anbudsgivaren menar (vilket i vissa anskaffandeformer är tillåtet). Det kan också vara svårt att beskriva tydliga betygskriterier i förväg vilket skulle kunna ge problem ifall man råkar ut för överprövning. 2 LOU: Lagen om Offentlig Upphandling (1992:1528)

Sambrplform_vagledn_OTP_v20.doc 6(9) Men, såsom tangerades i inledningen, att inte råka ut för överprövning garanterar inte på något sätt att det bli en nyttig lösning för verksamheten, det krävs betydligt mer. Å andra sidan riskerar det att inte bli någon lösning alls ifall man förlorar i överprövning. Denna variant, att be om lösningsförslag kan vara extra värdeskapande då ett område är nytt och det inte utvecklats tydliga "best practices" ännu. Likväl är det även här viktigt att skriva ner betygskriterier i förväg så att riskerna kan motverkas. Ifall man arbetar med någon slags community för öppen programvara bör kravformuleringar kunna vara mycket bra utgångspunkter för ett communitys interna arbete att vaska fram bästa lösning. 2.1.4. Ge kravbild för ev skräddarsydd systemutveckling Typiskt tillfälle: LOU-upphandling (särskilt vid förhandlad upphandling), ramavtals-avrop, direktupphandling, skräddarsydd utveckling mot konsultramavtal, öppen programvara mm. Typisk kravsort: Skall-, Bör-, Beskriv-krav Kommentar: Denna anskaffandevariant kan ha olika karaktär, alltifrån att starta med en mycket detaljerad specifikation i LOU-fallet till att ha en grundspecifikation och sedan arbeta iterativt med s k agila metoder där specifikationen/lösningen förädlas stegvis i tätt samarbete mellan användare och leverantör. Klart är dock att LOU-aspekter på kravtexterna blir mindre betydelsefulla och det konkreta nytto- eller teknik-innehållet i anbudssvar, t ex av Bör- och Beskriv-typen, blir prioriterade. 2.1.5. Få in textmaterial för senare kontraktsskrivning. Typiskt tillfälle: Alla anskaffanden (utom där kontraktstexten är fördefinierad). Typisk kravsort: Skall-, Bör-krav med Beskriv-uppmaning, Fristående Beskriv-krav. Kommentar: I detta fall är idén att dels först utvärdera på sedvanligt sätt men därefter vara noggrann med att ta in Beskriv-svaren i kontraktet så att det går lättare att vara tydlig mot leverantören i senare skeden. Se även nedanstående punkter. 2.1.6. Samla på råmaterial till senare förhandling Typiskt tillfälle: Alla anskaffanden Typisk kravsort: Alla krav-svar Kommentar: Här är fokus att set till att väl ha dokumenterat alla utfästelser från leverantören. I nästan alla leveranser är det tyvärr något som inte blir helt lyckat från leverantörens sida, och alltid är det något som det kan hävdas att kunden själv inte skött till 100%. Detta ger vanligen en förhandlingssituation i ett sent skede där man troligen kommer att ge och ta i någon slags kompromiss. I detta läge behöver kunden ha "bränsle" till förhandlingsbordet. Viktigt blir att inte bara dokumentera kravssvar (inklusive Beskriv-svar) från upphandlingen utan även annat bränsle såsom publicerade förstudier, dialog under projektets gång (dokumentera dialogen, särskilt t ex e-post), projektmötesprotokoll, testprotokoll mm.

Sambrplform_vagledn_OTP_v20.doc 7(9) 2.1.7. Samla på råmaterial till senare stämning Kommentar: Denna punkt är mycket lik föregående, med den skillnaden att man faktiskt går till rätts för att få prövat leveransen. Detta är förstås ovanligt i praktiken, man hoppas att man aldrig ska behöva gå så långt. Förhandlingar enligt föregående punkt är istället det helt dominerande sättet att lösa sådana här problem i Sverige. Dock, skulle det bli en rättssituation behövs dokumentation enligt ovan, inklusive diverse Beskriv-svar i anbudsdokument. Svensk rätt baseras på s k fri bevisprövning vilket gör att rätten ska göra en samlad bedömning både av "hårda" juridiska förhållanden såsom undertecknade testprotokoll och avtal, men även av många andra sorters underlag som nämnts ovan. 2.1.8. Driva marknaden roadmap Denna motivering handlar om att skriva krav för att påverka leverantörer att på sikt skapa lösningar med vissa önskvärda egenskaper. Se även kapitlet Roadmap - krav på sikt i ÖTP.

Sambrplform_vagledn_OTP_v20.doc 8(9) 3. BETYGSKRITERIER ÖTP:s kravpunkter inkluderar inte betygskriterier. Detta beror främst på att betygskriterierna bör bero av aktuella verksamhetsbehov, kommuns IT-strategier mm. De beror också av hur man i ett anskaffande valt att vikta olika krav mot varann. Dock bör det vara en god potential att kunna återanvända även betygskriterier emellan faktiska anskaffanden. Här finns två aspekter. Det ena är att det ska gå att göra en objektiv utvärdering av anbuden. Det andra är att anbudsgivarna rimligen ska kunna förstå vad det är som betygssätts mer positivt än något annat, så anbudsgivaren i sin offert t ex kan avväga mellan fullödighet i lösningen och prissättning. För vissa krav är det självklart vilken typ av svar som ger högre utvärderingsbetyg, men om så inte skulle vara fallet är det mycket viktigt att det i refererande text i ett icke-funktionellt kravdokument åtminstone grovt framgår hurdana betygskriterierna är. Upphandlaren bör för att eliminera godtycklighet ha en förteckning för varje ställt krav med mer noggranna betygskriterier. I vissa upphandlingskulturer publiceras dessa detaljerade betygskriterier, i andra fall är detta ett internt arbetsdokument. Nedan inkluderas ett exempel på hur ett ÖTP-krav kan förses med betysgkriterier: ÖTP-exempelkrav-1: Att lösningen går att konfigurera så att olika inloggningslösningar stöds, såsom eid, användarnamn/lösenord, SMS-engångskod etc. Beskriv konfigurerbarheten och vilka inloggningslösningar som stöds. I icke-funktionellt kravdokument tänker vi oss att det står: Lösningen bör uppfylla ÖTP-exempelkrav-1. Anbudsgivaren skall beskriva lösningen ifall den erbjuds. Betygskriterierna kan då tänkas vara (i detta exempel används en fast betygsskala om 0-4 som sedan viktas): 0 poäng = Nej-svar eller ingen beskrivsvar. 1 poäng = Ja-svar, men mycket kortfattat beskrivsvar 2 poäng = Ja-svar, två inloggningslösningar stöds 3 poäng = Ja-svar, fler än två inloggningslösningar stöds 4 poäng = Ja-svar, fler än tre inloggningslösningar stöds Nedan inkluderas även ett exempel på betygskriterier i fall då det är svårt att ange exaktare alternativ enligt ovanstående exempel, t ex då anbudsgivaren ombetts föreslå en lösning (se ovan). Härvid är det extra viktigt att skriva ner hur bedömningen av anbuden sedan gjordes. 0 poäng = Nej-svar eller ingen beskrivsvar. 1 poäng = Ja-svar, men mycket kortfattat beskrivsvar 2 poäng = Ja-svar, relativt omfattande beskrivsvar men med någon tydlig brist 3 poäng = Ja-svar, relativt omfattande beskrivsvar utan tydlig brist, samt

Sambrplform_vagledn_OTP_v20.doc 9(9) fullödig lösning 4 poäng = Ja-svar, omfattande beskrivsvar utan tydlig brist,, samt fullödig lösning Ett tips för att våga ställa beskriv-krav som kan leda till en bättre lösning men misstänks ge bedömningssvårigheter, samt kritik mot betygssättning, är att istället använda en expert-panel för bedömning av beskriv-svaren. Denna panel kan utgöras av en mix av intern och extern personal och behöver inte medföra speciellt stora extra kostnader. Expert-panelen har mycket god potential att kunna göra en fullödig bedömning av anbudsgivarens förslag och beskrivsvar. Det brukar även vara vettigt att skriva en generell formulering om att beskriv-svar max får vara på en A4-sida vid typsnittsstorlek 10, e dyl.