1 ÖTP - Öppen Teknisk Plattform Arlanda 2008-04-23 Verksamhetsutveckling & sambruk av kommunala e-tjänster.

En presentation över ämnet: "1 ÖTP - Öppen Teknisk Plattform Arlanda 2008-04-23 Verksamhetsutveckling & sambruk av kommunala e-tjänster."— Presentationens avskrift:

1 1 ÖTP - Öppen Teknisk Plattform Arlanda 2008-04-23 Verksamhetsutveckling & sambruk av kommunala e-tjänster

2 2 Agenda ÖTP-spåret 15.00-15.30 Inledning, kort om dagsläget, årsplaneringen för ÖTP Ann-Charlotte Ruderfors 15.30-16.50 Minikurs i upphandling av IT med hjälp av ÖTP 2.0 Genom att återanvända färdiga krav från ÖTP 2.0 finns en stor potential att snabba upp arbetet med förfrågningsunderlag, samt att inte riskera missa viktiga krav. Sven-Håkan Olsson 16.50-17.00 Bensträckare 17.00-18.00 Trendspaning för IT, baserat på Gartner Symposium nov 2007 Sven-Håkan Olsson

3 3 Några tänkbara punkter för ÖTP-året Mindre uppdatering till ÖTP v2.1 Skapande av Introduktion till ÖTP (lättläst för icke-tekniker) Förhoppningsvis deltagande i verksamhets/anskaffande-projekt inom Sambruk Skapa några utsnitt av krav-specar för några typanskaffanden och typiska kommunmiljöer

4 4 Minikurs i upphandling av IT med hjälp av ÖTP 2.0

5 5 Öppen Teknisk Plattform 2.0 Mönstren i ÖTP ger den tekniska basen för att skapa hängrännor och andra önskade lösningar utifrån komponenter/tjänster Komponenterna utgörs i sin tur vanligen av anskaffade verksamhetssystem – men de måste vara öppnare än många är idag Anskaffningsformen kan variera: Licensiering, köp av tjänst, köp av källkod, öppen programvara mm ÖTP är en specifikation och mönsterkatalog, inte en faktisk programvaruimplementation

6 6 1.2 => 2.0 ÖTP v1.2 (föregående version, 2005) –Tekniska mönster för integration, främst för e-tjänster –Resonerande avsnitt för att driva på marknaden (roadmap för leverantörer) –Har bilagts vid ett antal upphandlingar och fungerat som ett sätt att uttrycka inriktning gentemot leverantörer ÖTP v2.0 (senaste version, 2007) –Behållit samt vidareutvecklat innehållet i v1.2 –Tillfört en helt ny struktur för kravdokument vid anskaffanden –Potential att vara ett konkretare stöd vid dialog med IT-leverantörer

7 7 Icke-funktionella bilagor Anskaffanden av IT-stöd till verksamheten görs vanligen med –en funktionell kravspecifikation – verksamhetskraven –en icke-funktionell kravspecifikation – kringkrav, krav för driftning, teknik, samklang med annan IT mm Icke-funktionell kravspec bör rimligen kunna återanvändas i många anskaffanden –Idé från Botkyrka och Sambruk –Icke-funktionell spec inom Sambruk ska vara i stark samklang med ÖTP. –Nya ÖTP V2.0 innehåller en stor mängd återanvändbara icke- funktionella krav, som palett att utgå från i många anskaffanden. Den som ska upphandla väljer hur mycket man vill använda.

8 8 Ramavtal och EU-regler Anskaffanden kan förbilligas mycket ifall man slipper en komplett upphandling och kan göra avrop ifrån ramavtal istället. För nyare ramavtal anges vilken ”nyare EU-princip” man måste använda: –Rangordning (då är det redan givet i ramavtalet vem man först måste fråga, endast om de inte kan leverera får man gå till tvåan, osv) –Förnyad konkurrensutsättning (då måste ett nytt avrops- förfrågningsunderlag faktiskt skickas ut till de som har ramavtal, och en betygsutvärdering göras, vilken kan tänkas överklagas!) Det kommer att bli en explosion av behov av kravspecar! ÖTP2 kan förenkla genom återanvändning av kravtext...

9 9 Hur krav/dokument förhåller sig till varann Icke- funktionell kravbilaga Pekar ut (refererar) krav ur paletten - samt anger andra krav ÖTP-GIT Gemen- samma IT-krav Palett av krav i ÖTP v2.0 Aktuell situations verk- samhets- behov Kommu- nens IT-strategi- krav Sambruks visioner Påverkar Pekar ut Drift-krav

10 10 NrKravFör verifiering, skall lösningen beskrivas på bilaga 1 Lösningen skall uppfylla ÖTP-GIT 4.1 Ja 2 Lösningen skall uppfylla ÖTP-GIT 5.1.4 Nej... Kort icke-funktionell bilaga pekar ut skall-krav... ex:

11 11 NrKravFör bedömning, skall ev lösning beskrivas på bilaga Maxbetyg 1 Lösningen bör uppfylla ÖTP-GIT 6.1 Ja5 2 Lösningen bör uppfylla ÖTP-GIT 7.1.4 Nej10 3 Lösningen bör ha stöd för Sun Solaris 10 [Exempel på ett mer specifikt krav än vad som fanns i paletten och som en anskaffare kan tänkas ha - förtecknas direkt i text här] Ja5... Kort icke-funktionell bilaga pekar ut bör-krav... ex:

12 12 Vad har man kravskrivningar till? Selektera bort leverantör (LOU). Skall-krav. Betygsätta leverantör, kora vinnare (LOU, avrop, direktupphandling). Bör-krav, beskriv-krav. Ge kravbild för ev skräddarsydd systemutveckling Få in textmaterial för senare kontraktsskrivning. Skall-, bör- och beskriv-krav. Samla på råmaterial till senare förhandling (alltid är det nåt som inte blir lyckat, och alltid är det nåt man själv inte gjort 100% - då måste man ha bränsle till förhandlingsbordet sen). Alla svar, all dialog (dokumentera den!). Samla på råmaterial till senare stämning om det skulle bli så illa – fri bevisprövning i svensk rätt. Alla svar, all dialog (dokumentera den!). Driva marknaden – ”roadmap” – (sådana här lösningar vill vi ha – bör-krav nu, skall-krav sen!)

13 13 Användningsexempel Samma struktur som ÖTP:s kravpalett: –Botkyrka, för anskaffning av rekryteringslösning. –Flera andra Botkyrka-anskaffanden (man planerar nu gå över till ÖTP2.) –Jönköping, för anskaffning av utbildningsplattform mm –Använda dok-exempel nedan (finns på sambruk.se): ÖTP2: ÖTP version 2.0 Jkp: Jnkping_Icke-funktionella krav - Utbildningsplattform 1.0 070213.doc GIS-IT: Jnkping_Generella_IS-IT_krav_1.0.doc

14 14 Hur sätter man ”betygen” för att kora vinnaren? Skall-kravssvaren är ovillkorliga och kan alltså inte ges betyg Bör-kravssvaren måste ges betyg –Det är alltså viktigt att kraven ställs så att det är rimligt lätt att utvärdera svaren –Å andra sidan får inte kraven bli räddhågsna av denna anledning, då kommer man att få en usel lösning Dessa betyg ska viktas på ett för aktuell upphandling lämpligt sätt –T ex Egenskaper 60%, pris 40%, sedan vidare uppdelat Viktningen ska åtminstone på övergripande nivå vara publicerad i förfrågningsunderlaget

15 15 Exempel på vikthierarki (Verva Prog07)

16 16 Viktprinciper Fall inte för frestelsen att sätta alltför hög vikt vid pris – egenskaperna hos en IT-lösning är mycket viktiga! Stil 1: Varierande maxpoäng –Varje bör-krav ges maxpoäng som kan vara olika. Ex ett viktigt krav får max 10p, ett mindre viktigt får max 2p. Mycket enkelt att räkna ihop. Stil 2: Maxpoäng gånger vikt (fg sida) –Maxpoäng alltid samma för alla krav, t ex kan man ge 0 – 4 –Poängen multipliceras sedan med vikt innan summering –Den vanligaste metoden, man slipper tänka olika max vid svarsbedömningen. Dock komplexa uträkningar och felrisker.

17 17 Skall-krav eller bör-krav? Skall-kraven bör ju egentligen vara de viktigaste, men problemet är att man då inte kan rangordna offerenterna just med avseende på det viktigaste! Om man istället gör högviktade bör-krav som kan ge rangordning kan man riskera att nån leverantör får kontrakt som är dålig på en riktigt viktig sak Förslag i sådana fall: –Sätt ett ”golv-krav” med skall-krav dvs lägsta acceptabla nivå. –Sätt ett bör-krav med högre kravnivå än golv-kravet, så att det också går att rangordna

18 18 Räddhågsna krav? Kravsvaren måste bedömas objektivt Överklagan/överprövning händer då och då, särskilt när flera offerenter hamnat nära varann i betyg – eländigt ifall man måste göra om upphandlingen Det måste vara rimligt förutsägbart för offerent vad det är som kan ge högre betyg –Ibland är det lämpligt att kort skriva vid kravet vad som grovt sett krävs för poäng 2, 3 osv Om ett krav verkligen skulle behövas men man är orolig för objektivitetsklander: –Använd expertpanel, kanske tre oberoende och erfarna i branschen –Panelen gör en bedömning av längre textsvar, sätter betyg, dokumenterar varför. –Behöver inte bli dyrt, tidsåtgången är inte så stor. Var inte rädd för att be om förtydliganden från offerent om svaren är suddiga, men se upp med likabehandlingen – ibland ställer man samma fråga till alla därför.

19 19 Måste man ha en massa bör-beskriv? Man kan tycka att de funktionella kraven ofta borde räcka – varför ska vi behöva ”skåda hästen i munnen”? Problemet är att om det strular, även om vi finge vite så får vi inte den lösning vi ville ha vid rätt tidpunkt Vi bör därför göra rimlighetsbedömning av en del icke-funktionella saker – behövs beskriv-frågor

20 20 Bör-beskriv forts Å andra sidan, varför kan vi inte bara beskriva hur vi vill ha det, som krav, varför ska vi bedöma offerenternas svar? Jo, ofta finns det många alternativa sätt att lösa ett krav som är helt OK –Det kanske går att göra på 100 sätt –70 är bra, 30 är dåliga –Det är omöjligt att speca alla de 70, vi måste lägga det i knät på offerenten att beskriva vad de gjort, så får vi bedöma det –Använd egen kompetens eller t ex expertpanel

21 21 Hur komma ifrån att Skall-Ja egentligen inte uppfylls? Problematiskt att offerenter kryssar i lite för lättvindigt – parallellt med att det offentliga mycket sällan stämmer leverantör även om ett kryss varit klart osant. Idéer: –”För att verifiera detta krav skall er lösning beträffande denna fråga beskrivas:” + beskrivruta –Går det att göra om till Bör-krav med mycket hög vikt istället? –Lägg åtminstone saken på ”vedtraven för framtida förhandlingsbränsle i händelse av leveransproblem”

22 22 Hur ställer man prestandakrav ifall driftningen sker inom kommunen? Idé, t ex: –Krav: Att offerenten specar en tänkt lämplig serverbestyckning för en kommun av er storlek –Krav: Att med just denna serverbestyckning ska man klara t ex att 99,5% av anropen klaras inom 3 s –På motsvarande sätt vad gäller ”uptime”

23 23 Några övriga tips Skriv inte negativa krav utan ifyllnadsanvisning; –”Lösningen skall inte använda applets” – vad betyder det sen ifall offerent kryssat i Ja? Tänk ut hur acceptanstest ska gå till. Ett förslag finns i ÖTP v2.0 kapitel 6.2 Krav-idéer påkomna efter ÖTP v2.0 finns på sambruk.se i: –anteckningar_till_OETP_v21_2008-04-22.doc

24 24 Sven-Håkan Olsson Sambruk / DocAccount 0708 – 84 01 34 sven-hakan.olsson[hos]docaccount.com Verksamhetsutveckling & sambruk av kommunala e-tjänster Sambruk_Arlanda_OETP_2008-04-23_v1.ppt