Viktiga moment i en IT-upphandling - kort om inlåsning - kravarbetet - avtalsarbetet - ÖTP som upphandlingsstöd - typupphandlingar Anders Thoursie, VD och konsult hos DocAccount AB (inom kort IT-strateg hos Järfälla kommun) 2009-01-21
Kort om inlåsning
Affärsmodellerna förändras eller? Vem äger vad i ett IT-system olika typer av inlåsning Många aktörer har haft, och har än i dag, svårt att anpassa sin affärsmodell till en värld där systemen har öppna gränssnitt och tillgängliggjorda informations- och datamodeller. Det är här som den öppna källkodstrenden trycker på traditionella systemleverantörer. Många affärsmodeller har byggt på, och bygger ännu på, inlåsning Olika typer av inlåsning Teknisk inlåsning Icke-existerande eller otillräckliga maskingränssnitt, funktionellt sett Olämpliga maskingränssnitt, tekniskt sett Icke-dokumenterad datalagring Semantisk inlåsning definitioner av olika begrepp / informationselement enligt en semantisk modell som är olämplig eller svåröversättbar
Affärsmodellerna förändras eller? Vem äger vad i ett IT-system olika typer av inlåsning Olika typer av inlåsning, forts Inlåsning eller andra effekter pga affärsmodell eller juridiska villkor Infrastrukturkomponenten e-id eller nyss aktuella Google Chrome Nya skepnader, nya affärsmodeller och nya aktörer Många större företag gör stora omsvängningar kring vad som ska utgöra kärnaffären Sälja information, sälja kunskap/konsulting, sälja support, sälja tjänster Systemleverantörernas nya affärsmodeller kanske en diskussionspunkt till paneldiskussionen
KRAVDIALOG eller Konsten i att förstå sin egen verksamhet och beskriva den
Helikopterperspektiv - utveckling i samspel Marknad (& konkurrenter) Tjänster Kunder Juridik & avtal Affärsutveckling Tjänsteutveckling Organisation Roller & ansvar Processer Rutiner Verksamhetsutveckling Teknikutveckling
Helikopterperspektiv - utveckling i samspel Affärsutveckling Tjänsteutveckling Kundtjänst, fakturering, Kundnära processer Gränssnitt mot partner / leverantörer Verksamhetsutveckling Helt interna processer Teknikutveckling
Olika typer av systemstöd Marknad & konkurrenter Tjänster Kunder Juridik & avtal Affärsutveckling Tjänsteutveckling Organisation Roller & ansvar Processer Rutiner Tjänsteplattform (IT som kärnverksamhet / produktionsmiljö) Kundwebb Kundadministration Verksamhetsutveckling Teknikutveckling Administrativa stödsystem (ekonomi, personal, dokument- & ärendehantering )
Olika metoder vid kravarbete Affärsutveckling Tjänsteutveckling Nyttovärdering Processer Verksamhetsutveckling Begreppsanalys Use case (kravanalys) Teknikutveckling Klassdiagram (begrepps- / dataanalys) Use case (design-verktyg) Objektsmodeller
Men vad är behovet / problemställningen? - exempel på frågeställningar - Tekniktrender? - Vilka är kundbehoven? - Vilka tjänster ska vi erbjuda och hur? - Vilka är aktörerna på vår marknad? - Vilka skall vi samverka med och varför? Affärsutveckling Tjänsteutveckling Vilka är våra kunder egentligen? Vilken service-nivå skall vi ha på kundtjänst? Föränderlig kunskap om kunderna / marknaden Föränderliga affärsmål Verksamhetsutveckling Vem ansvarar för kvaliteten i våra tjänster? Otydliga roller Manuella och informella arbetssätt Teknikutveckling
Olika problem kräver olika metoder Affärsutveckling Tjänsteutveckling Nyttovärdering 15 3 Svårvärderad nytta 7 Indirekt Nettoresultat- nytta 12 påverkande nytta Direkt 5 3 resultatpåverkande Kostnad för nytta nyttan Processer Verksamhetsutveckling Collaboration diagram Tillståndsdiagram Begreppsanalys Use case (kravanalys) Sequence diagram Teknikutveckling Swimlanes Use case (design-verktyg) Klassdiagram (begrepps- / dataanalys) Objektsmodeller
Programvarubolag Hårdvarulevera ntör, Di strib utör Infrastruktu r- leverantör Utveckla produkter och tjänster Utveckla teknisk infrastrukur Utveckla administrativa affärssystem Ekonom i Kompetensförsörjning (HR) Marknadsföring boxar Kundadministraion Sälja Hyrd infrastru ktur Drift och förvalt ning ny konsumentkund fakturaunderlag ky kund nya produkter och tjäsnter ny infrastruktur effektiva stödsystem ekonom itjänster kompetent personal kunskap om företages produkt er hos allm änheten Erbjuda kundservice Ta betalt Leverera produkter och tjänster I nstallerad, felf ri produktionsmilöje kundservice Kunder Processer ofta användbart Olika beskrivningstekniker (t.ex. UML) kan användas i olika kontexter. Affärsutveckling Tjänsteutveckling I analys av verksamhetsprocesser är det bra att driva analysen utifrån-och-in. Börja med att beskriva: varför genomförs en viss process vad skall åstadkommas, för vem? Dock finns en risk att alltför tekniknära beskrivningsmetoder leder till ett snävt bottom-up / inifrån-och-ut tänkande. Verksamhetsutveckling Collaboration diagram Tillståndsdiagram Sequence diagram Teknikutveckling Processdiagram Digital-TVbolaget Kärnprocesser Stödprocesser Idealt kan man se hur olika processer samverkar för att leverera tjänster till slutkunder. Swimlanes Idealt börjar man tänka värdekedjor på en övergripande nivå för att sedan beskriva detaljerade ärendeflöden / workflow i fördjupningsgrafer.
Processmodeller (verksamhet) Värdekedjor (strategiperspektiv) vilket värde skapar arbetet som utförs? Styrande förutsättningar förädlingsobjekt Process A Resurser Workflow vad görs i vilken ordning av vem? Detaljer! Process A Val Process B Parallellism Ärenden något med tydligt start / slut. Ex: felanmälan, bokning,
Processers koppling till information förädlingsobjekt 1 Process A förädlingsobjekt 2 Process C förädlingsobjekt 3 Process B förädlingsobjekt 4 Resurser Databas A Kartotek B Utrustning information 1 kompetens 1 maskin 1 information 2 information 3 kompetens 2 maskin 2 information 4 Kompetens
Det är viktigt att göra en avvägning kring hur djupt man ska gå i kravarbetet En detaljerad kravdialog kan bestå av (utvecklingsprojekt): Detaljerade processkartor / ärendeflöden Kartor + definitioner av begrepp som skall byggas in i systemet Detaljerade funktionsbeskrivningar, t ex i form av Användningsfallsöversikt Rutinbeskrivningar : word-dokument med instruktioner om hur olika arbetsrutiner skall utföras gärna med inklippta skärmbilder Icke-funktionella krav Vid upphandling, och viss anpassning, av standardsystem: Vissa processanalyser där funktionskrav tydliggörs Kravformuleringar kring viktiga funktioner/funktionsområden Icke-funktionella krav
Accesstjänst Tilläggstjänst som Obligatorisk kunden väljer tilläggstjänst Service Lagstadgat tillhandahållande av Mervärdestjänster grannlandskanaler Tvättstugebokningssystem Subventioneringstjänster Subventionering av modem för de boende i viss fastighet Subventionering av månadsavgift för de boende i viss fastighet Anslutning Grundtjänst för access Grundtjänst för villaägare Distribution (normal grundtjänst) Distribution med reducerat pris för fastighetsägaren (och högre pris för abonnenten) Grundtjänst för hotell Konsumenttjänst (abonnemang) Abonnemangstjänst Företagstjänst (abonnemang) D ig ita l- T V - bolaget H å rd v a ru - le v e ra n t ö r, D i s t rib u t ö r P ro g ra m v a r u - bolag I n fra s tr u ktu r- leverantör K ä r n p r o c e s s e r boxar K undad m inistraion Sälja H y r d in f ra s tru ktu r D rift o c h fö r v a lt n in g Accesstjänst Tilläggstjänst som Obligatorisk kunden väljer tilläggstjänst Service Lagstadgat tillhandahållande av Mervärdestjänster grannlandskanaler Centrala verksamhetsbegrepp Tvättstugebokningssystem Subventioneringstjänster E r b ju d a ny konsum entkund kundservice fakturau nderlag T a b e ta lt ky kun d Leverera pro dukter och tjänster Installerad, felfri produktionsm ilöje Subventionering av modem för de boende i viss fastighet Subventionering av månadsavgift för de boende i viss fastighet kund Anslutning Grundtjänst för access Grundtjänst för villaägare Distribution (normal grundtjänst) Distribution med reducerat pris för fastighetsägaren (och högre pris för abonnenten) Grundtjänst för hotell Konsumenttjänst (abonnemang) Abonnemangstjänst Företagstjänst (abonnemang) Hård varuleverantör, Di strib utör Pro gram varubolag I nfrastrukturleverantör Utveckla produkter och tjänster Utveckla teknisk infrastrukur Utveckla administrativa affärssystem Ekonomi Kompetensförsörjning (HR) Marknadsföring boxar Kundad ministraion Sälj a Hyrd infrastruktur Drift och förvaltning ny konsumentkund fakturau nderlag ky kund nya produkter och tjäsnter ny infrastruktur effektiva stödsystem ekonomit jänster kompetent personal kunskap om företages produkter hos allmänheten Erbju da kundservice Ta betalt Leverera produkter och tjänster I nstallerad, felf ri produktionsmilöje kundservice Kunder Översikt konsten i att förstå sin egen verksamhet och beskriva den! Begreppsmodeller / definitioner av -Tjänstestrukturer -Kunder, kundkategorier -Affärsmodeller Aktörer / roller på markanden Värdekedjor i marknaden Service Mervärdestjänster Tvättstugebokningssystem Subventioneringstjänster Tilläggstjänst som kunden väljer Subventionering av modem för de boende i viss fastighet Lagstadgat tillhandahållande av grannlandskanaler Subventionering av månadsavgift för de boende i viss fastighet Anslutning Accesstjänst Obligatorisk tilläggstjänst Grundtjänst för access Grundtjänst för villaägare Distribution (normal grundtjänst) Distribution med reducerat pris för fastighetsägaren (och högre pris för abonnenten) Grundtjänst för hotell Konsumenttjänst (abonnemang) Abonnemangstjänst Företagstjänst (abonnemang) Affärsutveckling Tjänsteutveckling Roller, organisation Företaget Säljavdelning Produktion Kundtjänst First line Analysgruppen Säljare Kundprojektledare Releaseansvarig Processdiagram (värdekedjor -> ärenden) Digital-TVbolaget Stödprocesser Kärnprocesser Verksamhetsutveckling Begrepp för systemet Detaljerade processkartor (ärendeflöden) Sequence diagram Collaboration diagram Kravdialog Teknikutveckling Användningsfall / rutinbeskrivningar/ Skärmbildsförklaringar Tekn design Tillståndsdiagram Klassdiagram
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. Samla på råmaterial till senare förhandling (alltid är det något som inte blir lyckat, och alltid är det något man själv inte gjort 100% - då måste man ha bränsle till förhandlingsbordet sen). Alla svar. Samla på råmaterial till senare stämning om det skulle bli så illa fri bevisprövning i svensk rätt. Alla svar. Driva marknaden roadmap (sådana här lösningar vill vi ha bör-krav sen, skall-krav nu!)
AVTALET
Avtalet På en mycket övergripande nivå kan man säga att avtalet reglerar två saker, leverantörens prestation och kommunens prestation Vid upphandling av t.ex. ett ekonomisystem + viss anpassning & implementation så är leverantörens primära prestation en färdig, och lyckad/accepterad, implementation av det upphandlade systemet Beroende på hur det upphandlas så är det kanske inte enbart ett system / en programvara som upphandlas utan kanske ett färdigintegrerat och fungerande system Kommunens (köparens) primära prestation är betalningen Det är viktigt att i avtalet tydliggöra vad som skall vara uppfyllt för att integrationsprojektet och leveransen ska anses vara uppfylld.
Mottagande av leveransen acceptanstestet Mottagandet av leveransen bör regleras genom ett (eller flera) acceptanstester. Denna procedur ska finnas beskriven i avtalet. Varje unik upphandling kräver då också att man upprättar en Testplan. Testplanen definierar hur kravspecifikationen kommer att tillämpas och kontrolleras i acceptanstestet. Testplanen definierar också vilken typ av fel som inte är acceptabla och händelser/åtgärder som ska vidtas från leverantörens sida. Testplanen, tillsammans med tydliga kravspecifikationer och gränssnittsbeskrivningar, utgör alla centrala avtalsdokument (bilagor) och måste vara framtagna i samband med att upphandlingen inleds (dvs efter RFI-fas). Testplanen måste tas fram i samverkan mellan den/de funktionella kravställarna och IS/IT (som oftast hanterar de icke-funktionella kraven).
Acceptanstest, betalningar och vite Acceptanstestet är också nyckeln i avtalet för att betalningar skall inledas. Försenad leverans kan leda till vite (och ultimativt till hävningsmöjlighet) Vitesklausuler är också ett MYCKET effektivt styrmedel för att säkerställa leverantörers fokus på särskilt viktiga krav i ett avtal. Detta verktyg ska naturligtvis inte användas till för många delar, men samtidigt ska man inte vara rädd för att lyfta fram kritiska krav/framgångsfaktorer och viteskoppla dem. En leverantör förstår viten och kommer att fokusera på att viten inte ska lösas ut.
Exempel på hur en bilagestruktur kan se ut vid ett licens och integrationsavtal Bilaga 1 Funktionell Specifikation Bilaga 2 Icke-Funktionell Kravspecifikation, jämte därtill hörande bilaga ÖTP v2.0 (ÖTP - Generella IS/IT-krav vid anskaffning av verksamhetsstöd) vilken skall anses utgöra en integrerad del därav. Bilaga 3 Tidsplan, jämte projektplan och projektorganisation Bilaga 4 Dokumentation Bilaga 5 Utbildning Bilaga 6 Gränssnitt Bilaga 7 Acceptanstest Bilaga 9 Priser och betalningsvillkor Bilaga 9 Rekommenderad hårdvara (Bilaga 10 Leverantörens licensvillkor) görs dock gärna som ett separat avtal (Bilaga 11 Leverantörens supportvillkor) görs dock gärna som ett separat avtal Bilaga 12 IT-företagens Avtal 90 version 2004
Centrala avtalsbilagor Kravspecarna (funktionell och icke-funktionell) Gränssnittsbilagan Testplanen (ingår som underbilaga till Acceptanstest -bilagan) Alla ovan nämnda dokument är centrala avtalsbilagor som bör vara tydliga. De, tillsammans med huvudavtalet, måste också finnas framme och ingå i upphandlingsunderlaget (dvs efter RFI-processen). Är de inte det så blir det svårt att ha någon reell möjlighet för kommunen att kontrollera leveransen (och därmed ha avtalsmässigt stöd i att peka på fel eller brister). Man kommer då inte heller ha möjlighet att hålla inne kommunens viktigaste prestation betalningen.
ÖTP SOM UPPHANDLINGSSTÖD
Syftet med ÖTP Att skapa teknisk interoperabilitet - en viljeyttring för ökad öppenhet! Dvs gemensamma standarder för de elektroniska gränssnitten mellan olika delar av de organisationer som omfattas av arkitekturen 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 vad många är idag ÖTP är en specifikation och mönsterkatalog ett upphandlingsstöd!
Öppenhet i ÖTP innebär det att = ÖTP öppen källkod? Nej, naturligtvis inte! Öppenhet som ÖTP syftar till siktar som sagt på interoperabilitet, snarare än licensformen. Öppen programvara som fenomen är bra, men i praktiken finns det fler överväganden att göra än enbart huruvida tillgången till programkoden kostar pengar eller inte Öppen programvara är inte gratis, utan skall snarast ses som gemensamfinansierad utveckling Det handlar om att balansera mellan kostnad initialt, kostnad på sikt och risk
Varför använda ÖTPs Generella IT-krav (GIT)? Återanvändning av redan gjort kravarbete för icke-funktionella krav, till många anskaffanden Ensning av kravbilden relativt kommunens IS/IT-vision Palett av krav så att man förhoppningsvis mindre lätt glömmer ställa vissa krav MEN one size does not fit all Kraven måste anpassas till varje anskaffande
Hur kravdokument förhåller sig till varann Aktuell situations verksamhetsbehov Kommunens IS/ITstrategi-krav Sambruks ÖTPinriktningar Ickefunktionell kravbilaga (Pekar ut krav ur paletten) ÖTP GIT - Gemensamma IT-krav (Palett av krav)
Exempel på refererande i krav Icke-funktionella krav Följande icke-funktionella krav skall uppfyllas: Nr Skallkrav Beskrivning 1 GISIT 6.1.1.1 (Samklang med kommunens inriktn.) 2 GISIT 6.1.1.2 (Uppgradering i enlighet med säkerhets- och teknikutveckling) 3 GISIT 7.2 (Drift i egen regi) Undantagvis kan enstaka komponenter/tjänster levereras som ASPs-tjänst 4 GISIT 7.3.1.6 (Beskriv mer detaljerade krav) 5 GISIT 7.4.1.4 (Beskriv mer detaljerade krav) 6 GISIT 8.1.1.1 (Klientdatorer Operativsystem) 7 GISIT 8.1.4.1 (TerminalServer) 8 GISIT 8.2.1.1 (Microsoft Server 2003) 9 GISIT 8.3.1.1 (TCP/IP) 10 GISIT 8.3.1.2 (HTTP/HTTPS) 11 GISIT 8.4.1.4 (LDAP v3) 12 GISIT 8.7.1.1 (Integration mot Novell GroupWise 7) 13 GISIT 9.1.1.1 (iframe/frame) 14 GISIT 9.1.1.3 (egen layout) 15 GISIT 9.1.1.4 (layout med style sheet) 16 GISIT 9.2.1.1 (SingeSignOn) 17 GISIT 10.1.1.1 (Händelseinformation till handläggare/medborgare) 18 GISIT 10.1.1.2 (Händelseinformation anpassad till WM-datas LEX) 19 GISIT 10.2.1.1 (Diariekrav) 20 GISIT 10.3.1.2 (HelpDesk för driftpersonal)
Tre typupphandlingar baserade på Öppen Teknisk Plattform version 2.0 30
Varför typupphandlingar? Till Öppen Teknisk Plattform (ÖTP) version 2.0 infördes ett stor palett av ett antal färdiga kravformuleringar som tänktes kunna återanvändas i många avrop/upphandlingar, både inom Sambruk som helhet och i enstaka kommuner. Tanken med att skapa typupphandlingar är att minska arbetsinsatsen inför varje anskaffande, genom färdiga icke-funktionella kravspecifikationer. 31
Tre typupphandlingar 1. Applikation som driftas internt (även med extern e-tjänst) 2. Applikation driftad som ASP-tjänst (e-tjänst inkl att applikationens serverdel ligger inom tjänsten). 3. Integrationstung applikation (t.ex. metakatalog) 32
Bedömningskriterier Ett stort värde i dessa typupphandlingars kravspecifikationer är de bedömningskriterier som har skapats till respektive betyg (G för skallkrav och 0-4 för bör-krav). Huruvida bedömningskriterierna ska publiceras/offentliggöras i samband med upphandling får avgöras från fall till fall. Vidare finns det också förslag till öppen text för flera krav. Denna text är tänkt att offentliggöras i upphandlingen och syftar till att utgöra visst stöd till tolkning av kravet. Det finns även kommentarer till de flesta kraven, men som är avsedda enbart för upphandlaren. 33
OBS! Viktigt Typupphandlingarnas kravspecifikationer ersätter naturligtvis INTE att man inför varje anskaffande självständigt värderar vilka krav som är viktiga och anpassar dem efter behov (stryker, ändrar och lägger till) En rekommendation är att avtalet efter upphandling refererar offert- /avropssvaren direkt så dessa är användbara i eventuella senare leveransdispyter 34
Exempel från Jönköpings kommun
Vilka åtgärder har Jönköpings kommun vidtagit? Infört en IS/IT-policy och IS/IT-strategi som understryker vikten av öppenhet och interoperabilitet i plattformsbeslut Slagit fast att ÖTP alltid, i kommunens alla systemupphandlingar, ska utgöra grunden för den icke-funktionella kravspecifikationen Arbetat fram avtalspaket som säkerställer leverans, färdig implementation och ansvar
anders.thoursie@docaccount.com 0732-680 400