Underlag för upphandling av beställningssystem för Linköpings universitet

Transkript

1 Underlag för upphandling av beställningssystem för Linköpings universitet Linköpings universitet genomför en förhandlad upphandling av beställningssystem. Härmed inbjudes Ni att lämna en intresseanmälan i enlighet med förutsättningarna i detta underlag. Sista dag att lämna intresseanmälan: Anmälans giltighet: 3 veckor efter sista anmälningsdag 1(13)

2 UNDERLAG FÖR UPPHANDLING AV BESTÄLLNINGSSYSTEM FÖR LINKÖPINGS UNIVERSITET 1 INLEDNING 3 Förord 3 Bakgrund 3 Upphandlande enhet 3 Upphandlingsform 3 Frågor avseende underlaget 3 Urvalsprincip 4 Anbudsutvärdering 4 BESKRIVNING AV SÖKT FUNKTIONALITET 5 Övergripande säkerhetskrav 5 Formella krav 5 Krav på juridisk acceptans 5 Säkerhets- och behörighetsfunktioner 5 Tekniska krav på drift och driftsäkerhet 6 Generella systemfunktioner 6 Grafiska användargränssnitt 6 Öppna system 6 Allmänt 6 Avtalsinformation 6 Partsinformation adressregister och roller 7 Artikel- och prishantering 7 Andra konkurrensutsättning 7 Beställningsmallar 7 Integration med produktions- och lager/förrådssystem 7 Skapa och sända ett avrop 8 Attestering 8 Behandlingsgång vid attest av avrop 8 Inloggning för avrop 8 Avropsbevakning 9 Inleverans och matchning 9 Inleverans 9 Matchning 9 Överföring till och från ekonomiredovisning 10 Periodisk fakturering 10 Översikt 10 Faktureringsobjekt 10 Uppföljning och statistik 10 Behandla faktura med andra fakturalösningar 11 Andra tjänster 11 Stöd för anslutning av varu-/tjänsteleverantörer 11 Utbildning 11 Användarförening 11 KRAV FÖR KVALIFICERING 12 Krav på anbudsgivaren 12 Ekonomisk stabilitet 12 Utvärdering 12 Referensuppdrag 12 Organisation 13 Bilaga 13 2(13)

3 Inledning Förord En kravspecifikation för systemstöd för beställningssystem har tagits fram inom ramen för det projekt som drivits inom Linköpings universitet med avsikt att införa effektivare handel genom automatisering innan år Bakgrund Linköpings universitet (LiU) har anställda, 1400 forskarstuderande och studenter inom grundutbildningen samt en ekonomisk omslutning på ca 2,5 mdr. Utbildning och forskning bedrivs inom fyra huvudområden: Tekniska högskolan, Filosofiska fakulteten, Utbildningsvetenskap och Hälsouniversitetet. Merparten av verksamheten är koncentrerad till Linköping, men det finns även en växande verksamhet i Norrköping. Viss utbildning finns dessutom i Vadstena och Stockholm. Som stöd för universitetets verksamhet handlas varor och tjänster för omkring 500 mkr årligen från ett mycket stort antal leverantörer. LiU använder i hög utsträckning statliga ramavtal men även lokala ramavtal, upphandlingar och direktupphandlingar utgör grund för inköp. Linköpings universitet ämnar upphandla ett beställningssystem för att erhålla ett stöd för elektronisk handel. System ska integreras mot ekonomisystem, Agresso 5.5, elektroniskt fakturahanteringssystem, Baltzar från Palette, och eventuellt mot dokumenthanteringssystem, Grow Business Public 360 från Software Innovation. Eftersom universitetet i dagsläget inte har något system för upphandlingsstöd kan universitetets dokumenthanteringssystem vara en tänkbar källa för avtalsinformation. Detta dokument innehåller en beskrivning av de funktioner vi önskar nå i vårt blivande system. Bedömning av leverantörens svar i formella anbud görs med utgångspunkt från denna beskrivning. I det här skedet är dock beskrivningen endast till för att visa omfattningen av det som ska upphandlas. Ni ska inte svara på den i det här skedet. Däremot ska de ställda kraven för kvalificering besvaras i er intresseanmälan. Upphandlande enhet Linköpings universitet Linköping Upphandlingsform Denna upphandling är en förhandlad upphandling enligt lag (1992:1528) om offentlig upphandling (LOU 5 kap 16 2 st) Frågor avseende underlaget Om leverantören önskar att förfrågningsunderlaget i något avseende ska förtydligas eller kompletteras ska sådan begäran ställas skriftligt per brev eller per e-post till catarina.wireklint@liu.se. Begäran ska ställas i så god tid att svar kan lämnas sex (6) dagar före anbudstidens utgång. Frågor ställda senare kommer inte att besvaras. 3(13)

4 Eventuella förtydliganden av förfrågningsunderlaget kommer att presenteras på Leverantören är själv skyldig att kontrollera att denne erhållit fullständigt material. Inlämnande av intresseanmälan Intresseanmälan ska: vara undertecknat av behörig företrädare för företaget. vara inkommet till Linköpings universitet, Registrator, senast Anbudsgivare svarar för att intresseanmälan kommer in i rätt tid. Anmälan som kommer in för sent tas ej upp till prövning. vara skrivet på svenska vara inkommet i slutet kuvert/paket vara tydligt märkt med Intresseanmälan Dnr: LiU 210/07-27 inges i original och två (2) kopior. Anmälan via e-post, telegram eller telefax accepteras inte. Intresseanmälan sänds till nedanstående adress alternativt lämnas personligen eller genom bud. Postadress: Besöksadress: Linköpings universitet Linköpings universitet Registrator Registrator, Hus Origo Linköping Linköping Öppettider: mån-fre Det finns en brevlåda vid ingången till hus Origo men denna har en begränsad kapacitet att ta emot anbud. Inkastet är smalt och är för litet för t.ex. en pärm. Urvalsprincip Efter löptiden för intresseanmälan (37 dagar) kommer Linköpings universitet att välja ut maximalt 5 leverantörer som har klarat kvalificeringsfasen. Se avsnittet Krav för Kvalificering för mer detaljer. Utvalda leverantörer får sedan lämna in formella anbud. Anbudsutvärdering Anbud kommer att bedömas utifrån det ekonomiskt mest fördelaktiga med hänsyn tagen till systemets kvalitet totalkostnad I systemets kvalitet inräknas bedömning av funktionalitet hur systemet fungerar för beställare respektive administratörer hur väl systemet anses kunna stötta universitetets inköps och fakturaprocess systemvisning och referenser förslag till genomförandeprojekt inklusive metod, tidplan och bedömd kostnad 4(13)

5 Leverantörerna kommer att bjudas in för att demonstrera sina system och för att svara på frågor kring offererad produkt. Visningen av systemen beräknas ske i maj, vecka 19, för de anbudsgivare för vilka detta blir aktuellt. Eftersom flera system kan bedömas leva upp till ställda krav kommer priset att få stor betydelse vid utvärderingen, det blir dock inte utslagsgivande. Hur väl systemen anses uppfylla ställda krav kommer i första hand att utvärderas genom att titta på anbudsgivarnas övergripande lösningar på de olika områdena. I andra hand beaktas hur väl kraven på detaljnivå uppfylls. Beskrivning av sökt funktionalitet Med elektronisk handel följer olika möjligheter att automatisera flöden av information, matcha samt kontrollera uppgifter maskinellt. Tilltro till systemet kan säkras om övergripande säkerhetskrav uppfylls, att formella krav enligt god redovisningssed följs och att juridisk acceptans för elektronisk handel erhålls. Övergripande säkerhetskrav Konfidentialitet, dvs skapa en behörighetsstruktur så att endast de som är behöriga ges tillgång till information. Integritet, dvs data skyddas mot manipulering under överföring, hantering och lagring. Spårbarhet, dvs krav på spårbarhet genom hela verifieringskedjan, loggning med tidstämpel vid attest och ändringar samt arkivering av räkenskapsinformation samt reviderbarhet av affärshändelser genom redovisningen. Tillgänglighet, dvs krav på att system och affärstransaktioner är tillgängliga i nutid och att historiska data är tillgänglig för uppföljning. Universitetet har en öppen datormiljö och en decentraliserad organisation vilket innebär att höga krav ställs på datasäkerhet. All lösenordsöverföring måste ske krypterat. Formella krav Elektronisk handel följer god redovisningssed Krav på säkerhet, till exempel kryptering, vid elektronisk överföring av affärshändelser Revisionella krav på spårbarhet för att uppnå en bibehållen verifieringskedja Krav på juridisk acceptans I ett legalt perspektiv, att innehållet är oförändrat och uppgift om vem som är avsändare framgår så att detta kan styrkas i domstol. Att i efterhand kunna kontrollera en transaktions tillkomst, dess avsändare och informationens riktighet, t.ex. kunna se vilka förändringar som skett från ursprungligt avrop. Att spårbarheten hålls intakt i minst 10 år för räkenskapsinformation samt i övrigt enligt gällande lagstiftning. Säkerhets- och behörighetsfunktioner I ett EH-system kan flera roller definieras, bl a avropare, godsmottagare, inleveransrapportör, handläggare av faktura, attesterare av beställning, attesterare av faktura, handläggare av abonnemang mm. I behörighetssystemet ska de personer som ska ha tillgång till systemet läggas upp. Dessa personer kan ha en eller flera av de roller som beskrivits. En persons behörighet ska alltså knytas till de roller som han eller hon har i verksamheten. Roller och personer ska kunna kopplas till olika 5(13)

6 organisatoriska enheter och nivåer. En säkerhetslogg ska logga alla otillbörliga försök att komma in i systemet och vilka som ändrat i vissa definierade informationstermer och databaser. Enkel administration efterstävas. Tekniska krav på drift och driftsäkerhet Om produkten erbjuds som sk ASP-tjänst ska leverantören beskriva sina rutiner kring drift och driftsäkerhet (Service Level Agreement). Vid lokal drift ska de tekniska krav som ställs på driftsmiljön presenteras. Oberoende av driftsform ska LiU förfoga över databasens innehåll och data ska kunna föras över via exempelvis ODBC samt exportfunktionalitet. Kommunikation med angränsande system ska beskrivas utifrån ett säkerhetsperspektiv. Generella systemfunktioner Grafiska användargränssnitt Den grafiska utformningen ska ha en informationsdesign som gör systemet lätt att arbeta med. Det ska vara lätt att använda funktionerna via det grafiska gränssnittet. Funktionerna ska vara pedagogiskt utformade och användarhjälp ska finnas via systemstöd. Webbgränssnitt är önskvärt för sällananvändare, med stöd för flera webbläsare som Internet Explorer och Mozilla Firefox. Öppna system Inom offentlig verksamhet eftersträvas öppen standard för elektronisk handel. Den dominerande branschstandarden i Sverige för elektronisk handel med offentlig sektor är Single Face To Industri, SFTI. Om SFTI inte används kan systemleverantör i stället ange annan likvärdig öppen standard som tillämpas i EH-systemet. Leverantören av e-handelssystemet ska då kunna visa eller göra troligt att denna alternativa standard är vanligt förkommande hos varu-/tjänsteleverantörer till staten. Flexibilitet avseende kommunikation och användargränssnitt ska finnas och vara öppna för diskussion. Befintlig teknik och defacto-standarder ska i möjligaste mån utnyttjas. Allmänt För att en beställning ska kunna göras krävs tillgång till avtalsinformation, partsinformation eventuell prislista eller möjlighet att hämta extern prislista alternativt möjlighet att göra en beställning utan motpart. Efter att beställningen är gjord ska ankomstmottagning liksom fakturamottagning för matchning ske. Sist i processen är statistiksammanställning och möjlighet till eventuellt efterarbete. Avtalsinformation Ett antal uppgifter i ett avtal har direkt intresse för att skapa och behandla avrop och kontrollera fakturor. Dessa grunddata behöver vara tillgängliga. Flera avtal kan knytas till en leverantör. LiU implementerar just nu dokumenthanteringssystemet Grow Business Public 360 och det kan komma att bli en källa för avtalsinformation. Beskriv vilka krav som ställs på källa för avtalsinformation. Alternativ till Public 360 kan föreslås. 6(13)

7 LiU använder i hög utsträckning statliga ramavtal. Information från dessa måste hämtas av beställningssystemet för att säkerställa korrekta avrop. Information hämtas från Statlig inköpssamordnings hemsida, Partsinformation adressregister och roller Leverantörsdatabas finns i ekonomisystemet, Agresso 5.5, och information ska hämtas därifrån av beställningssystemet. Det är ekonomisystemet som är huvudsystem för leverantörsinformation. För varje leverantör i partsregistret bör dessutom följande information kunna registreras: identifierande kod organisationens namn och fulla adress kontaktperson(er), med tillhörande kontaktinformation (telefon etc.) uppgifter om juridisk person: organisationsnummer, registreringsnummer för mervärdesskatt, ev F-skatt. Det är önskvärt att beställningssystemet använder information om beställare från universitetets elektroniska katalog (LDAP/AD) vid varje inloggningstillfälle. Artikel- och prishantering För att kunna göra ett avrop måste en förteckning över pris och sortiment vara tillgänglig för beställaren. Det kan vara via en lokalt, i beställningssystemet, administrerad lista, via den statliga ramavtalsdatabasen eller en extern webbplats. Då en lokal lista används måste den kunna administreras på ett enkelt sätt. Det gäller till exempel mottagning och publicering av lista, kontroll av innehåll, uppdatering av priser etc. I samtliga fall är det viktigt att informationen är sökbar på ett enkelt sätt. Andra konkurrensutsättning Vid en så kallad andra konkurrensutsättning måste systemet stödja den hantering som krävs för det. Beskriv hur en konkurrensutsättning utförs med stöd av systemet? Beställningsmallar För att underlätta avroparens arbete bör det finnas möjlighet att lägga upp olika former av beställningsmallar. De artiklar som läggs upp i mallen hämtas t ex från lokal prislista. En beställningsmall kan fyllas med artiklar från olika leverantörer. Hela beställningsmallen eller varje artikel bör kunna kontosättas (som ett alternativ till att kontosätta artiklar i prislista) så att kostnadskontering av avrop underlättas; kontosättningen behöver då kontrolleras mot gällande kontoplan. Varje mall ska kunna styras till olika leveransadresser som förval. Vid inläggning av uppgifter i mall som skapas eller ändras ska exempelvis artiklar i lokala prislistan eller leveransadresser kunna sökas på sökbegrepp som identitet, benämning, ord i benämning eller del av benämning. Av mallen ska framgå om artiklar hänförs till avtalat eller ej avtalat sortiment. När en mall fyllts i och godkänts av avroparen skapas ett elektroniskt avrop till respektive leverantör. Internt i EH-systemet bör det finnas spårbarhet mellan respektive avrop och godkänd beställningsmall så att ev fel i avrop som beror på felaktig beställningsmall internt kan spåras och rättas till. Integration med produktions- och lager/förrådssystem LiU har flera olika lager/förrådssystem som kan tänkas integreras mot ett beställningssystem i framtiden. Beskriv de möjligheter som beställningssystemet ger. 7(13)

8 Skapa och sända ett avrop Avrop mot ett ramavtal innebär att en avropare skapar en beställning Detta kan ske med stöd av en beställningsmall, hämtas från leverantörs webbshop eller ha satts samman av avroparen speciellt för det individuella beställningstillfället. När avroparen är klar med sitt underlag kan avropet attesteras. Det ska vara möjligt att kontosätta avrop om sådan information från prislista eller beställningsmall saknas eller behöver ändras. Innan ett avrop är attesterat eller sänt kan det ändras av avroparen internt i egna systemet. När avropet är godkänt, och eventuellt attesterat, kan det sändas till leverantören. Attestering Attestfunktioner kan variera mellan olika organisationer och verksamheter vilket kräver ett visst mått av flexibilitet. Behörighetsstrukturen ska kunna förändras löpande avseende byte av personer, roller eller organisatoriska förändringar. Till behörighetsstrukturen kopplas också attestbehörigheten. Även attesteringsprinciper bör vara flexibla, t ex genom att tillåta att attest får ske av en person men med möjlighet att följa upp vem och vad som attesterats. Det ska även vara möjligt att två olika principer får förekomma parallellt, t ex att för en köpare (eller för en viss avdelning) ska beställningen och fakturan alltid attesteras medan för annan köpare (eller avdelning) attesteras beställningen och mottagningen av varorna. Beskriv hur attestant uppmärksammas på inkomna ärenden. Vid intern uppföljning och revision ska ett ärende t ex behandlingen av ett avrop fram till betalning kunna följas. Det ska till exempel vara möjligt att se vem som attesterat ett avrop, vem som tog emot och godkände varorna, vem som tog emot fakturan och förde den vidare till betalning. Förutsättningarna för upprätthållande av god intern kontroll är dels att det i systemen kan byggas in automatiska maskinella kontroller men också att det finns funktioner för övervakning i systemet. Efter attest av fakturan är den klar för betalning. Följande attest och kontrollpunkter avses: attest av priskatalog attest av beställningar attest vid inleveransrapportering attest av faktura Behandlingsgång vid attest av avrop Ett avrop ska kunna attesteras innan det blir ett giltigt avrop. I samband med attest ska i systemet givna konteringar kunna ändras av den som attesterar avropet. I vissa verksamheter får inte attesten vara ett hinder för att genomföra och sända ett avrop till varuleverantören. En användare som är inköpsberättigad för en given verksamhet ska kunna upprätta, godkänna och sända avropet. Detta bör då också kunna matchas mot den attest/godkännande som sker vid mottagning av varor så att det finns två olika personer som attesterar avropet och som tar emot varan. Flexibel hantering eftersträvas. I de fall avropet är genomfört på leverantörens webb eller motsvarande så ska avropskopia kunna attesteras i efterhand om verksamheten så kräver. Inloggning för avrop I de fall avrop ska göras via webbutik kan det krävas inloggning vilket ska kunna hanteras på ett enkelt sätt. LiU har en lokal webbutik som systemet ska klara att ansluta mot utan extra krav på inloggning för beställaren. Beskriv förutsättningarna för att lokal inloggning kan användas. 8(13)

9 Avropsbevakning Avroparen och andra med samma behov ska kunna följa var i processen ett avrop befinner sig. Det innebär att avropet ges ett statusvärde som anger behandlingsläget, om avropet är attesterat (och av vem), sänt till leverantör, mottaget av leverantören men ej behandlat, bekräftat av leverantören (med ev ändringar), makulerat av köparen/leverantören, levererat av leverantören, fakturerat av leverantören, fakturan betald, etc. Möjlighet ska finnas att bevaka avrop och deras statusförändringar. Avroparen och andra med samma behov ska kunna bli aviserade när avrop nått mottagaren (varuleverantören). De kan även ha behov av att få bekräftat om leverantören kan leverera eller leverera med vissa begränsningar, t ex annat leveransdatum, eller avvikande eller restnoterad kvantitet. EH-systemet ska därför ha funktionalitet att ta hand om sådana aviseringar. Effekten av ett sådant ändringsmeddelande innebär att avropet justeras. Efter att avropet justerats kan det användas som en avstämningsuppgift inför inleveransen. Om avrop ändrats av leverantör kan ändringen medföra att avroparen vill annullera avropet eller ändra i leverantörens förslag. Inleverans och matchning LiU har ett EFH-system, Baltzar från Palette, för hantering av fakturor. Beställningssystemet ska integreras med detta för att skapa ett komplett e-handelssystem. Ankomstrapportering av beställda varor och tjänster ska antingen ske i Baltzar eller i beställningssystemet. Detsamma gäller för matchning av fakturor. Beskriv föreslagen gränsdragning mellan systemen. Inleverans Vid inleveransrapportering per avrop sker hantering av över-/underleverans, delleverans, ev restorderhantering, och notering om slutleverans. Olika typer av dokument kan utgöra underlag, t ex manuellt mot följesedel, med stöd av elektroniskt leveransaviseringsmeddelande eller leveransavisering med stöd för streckkodsavläsning. Inleveransrapporteringen skapar avstämningsunderlag inför fakturamatchningen. När inleveransrapportering utförs ska det vara möjligt att hantera mottagningsattest. Mottagningsattest ska kunna kopplas till behörighet. Resultatet från inleveransrapporteringen blir ett avstämningsunderlag som används av fakturafunktionen när matchning mot beställning sker. Delleveranser med avvikelser och/eller restnoterade artiklar ska kunna hanteras. Om det vid inleveransrapporteringen finns artikelrader som ej har inleveransrapporterats och rest tillåts, förväntas restrapporterade artiklar levereras vid ett senare tillfälle. Inleveransrapportering kan också genomföras utan tidigare registrering av avrop/beställning. Matchning Mottagen faktura ska kunna matchas mot avstämningsunderlag, t ex beställning och leveransinformation. Matchning kan ske antingen i Baltzar som då måste ha tillgång till beställningsinformation eller i beställningssystemet som hämtar fakturainformation från Baltzar. Beskriv kortfattat förslag på gränsdragning mellan systemen. Efter matchning går fakturan till ekonomisystemet, Agresso, för betalning. En sådan integration finns i dag mellan Baltzar och Agresso. 9(13)

10 Om matchning inte kan ske till exempel på grund av avvikelse mellan leverans och beställning, eller då attest saknas måste fakturan tas om hand så att avslut kan ske. Om attest saknas ska fakturan sändas för attest, om leverans saknas ska leverans inväntas, vid pris- eller kvantitetsavvikelse ska beställare informeras, etc. Överföring till och från ekonomiredovisning Efter det att matchning har gjorts för automatiskt betalningsgodkännande alternativt en manuell attestering för betalning har gjorts ska relevant information överföras till ekonomiredovisningen varifrån betalningen sker. LiU har ekonomisystemet Agresso 5.5. Periodisk fakturering Översikt Periodisk fakturering enligt ramavtal innebär fakturering av abonnemang, hyror mm, där underlaget till fakturan består av en s.k. stående order eller underlag som periodiskt faktureras. Systemet bör tillhandahålla en modell för hantering av periodiska fakturor på ett sådant sätt att automatisk matchning är möjlig. Samtidigt som det ska vara enkelt att kontrollera riktigheten i utförda betalningar och följa historiken i varje ärende. Faktureringsobjekt Med faktureringsobjekt avses mobiltelefonabonnemang, lokalhyror och andra s.k. stående order eller periodiskt fakturerade objekt. I avtal har prislista och andra villkor för de faktureringsobjekt som köparen använder i sin verksamhet specificerats. Ett faktureringsobjekt bör kunna registreras, ändras och tas bort. Det bör minst bestå av: objektets identitet namn innehavare eller avdelning som objektet tillhör kontrollgräns (min/max) för faktureringsobjektet konteringsrader planerad fakturaperiodicitet (per månad, per kvartal, per tertial...) kontrollgräns i antal dagar från föregående faktura attestant (beslutande chef) Uppföljning och statistik Syftet med uppföljning och statistik är att från historiska data kunna samla in och sammanställa avrops- och faktureringsstatistik under avtalsperioden, även på artikelnivå, för att följa upp köpmönster, avtalstrohet, leverantörsprestationer, sortiment, prisutveckling med mera. Informationen ska kunna sökas fram och sammanställas totalt eller nedbrutet på olika nivåer, t ex per leverantör, per leveransadress, per köpande enhet, per varugrupp eller per artikel. Exempel på information som ska kunna sökas ut är: vara/tjänst med artikelnummer och pris, leverantör, önskat respektive verkligt leveransdatum, ramavtal, avropare, leveransadress, avropad respektive fakturerad kvantitet samt avrops och fakturors värden. Användarna bör själva kunna styra sökkriterier och rapportuppbyggnad. Möjlighet ska finnas till överföring till externt format (Excel, XML eller motsvarande). 10(13)

11 Behandla faktura med andra fakturalösningar För leverantörer som inte har någon möjlighet att sända sina fakturor elektroniskt ska det finnas en möjlighet att via systemet registrera fakturor på webben för vidareöverföring till LiU:s EFH-system Baltzar. Andra tjänster Stöd för anslutning av varu-/tjänsteleverantörer För att snabbt komma igång med elektronisk handel måste det finnas leverantörer till de användargrupper som avropar varor. Vid nya upphandlingar kommer frågan med leverantörsanslutning som en del i den utvärdering och ev förhandling som parterna genomför. Även de leverantörer som redan har avtal med köparen kan behöva tjänster som underlättar leverantörsanslutningen. Flera typer av tjänster ska därför kunna erbjudas för att underlätta och påskynda anslutningen av leverantörer liksom administration av den löpande kund - leverantörsrelationen. Beskriv i förslag till genomförandeprojekt hur anslutningar kan göras. Utbildning I anbudet ska det ingå utbildning som krävs för administration av systemet likväl som den utbildning som krävs för teknisk personal vid en lösning med egen drift. Användarförening Om det finns en användarförening för systemet ska den beskrivas i anbudet. 11(13)

12 Krav för kvalificering Krav på anbudsgivaren Ekonomisk stabilitet För att kunna godtas som leverantör krävs att anbudsgivaren inte: är i konkurs eller likvidation, är under tvångsförvaltning eller är föremål för ackord eller tills vidare inställt sina betalningar eller är underkastad näringsförbud, är föremål för ansökan om konkurs, tvångslikvidation, tvångsförvaltning, ackord eller annat liknande förfarande. Anbudsgivarna ska vidare: ha fullgjort sina ålägganden avseende socialförsäkringsavgifter eller skatt i det egna landet eller i Sverige ha finansiell och ekonomisk styrka. LiU kan komma att begära uppgifter avseende riskklass/kreditvärdighet från Soliditet AB och vårt krav är lägst 3 som huvudkriterium. Enskild prövning av övergripande finansiell och ekonomisk styrka kan komma att göras om särskilda skäl uppstår. För bedömning huruvida anbudsgivare uppfyller ovanstående krav ska följande handlingar bifogas anbudet: intyg avseende registrering i aktiebolags- eller handelsregister eller motsvarande register intyg som visar att leverantören betalat socialförsäkringsavgifter och föreskrivna skatter i det egna landet eller i Sverige de två senaste årsredovisningarna med revisionsrapporter. För anbudsgivare som ska lämna uppgifter beträffande skatte- och avgiftskontroll i Sverige ska blankett Begäran om upplysningar vid upphandling användas. Blankett (SKV4820) kan hämtas på Skatteverkets hemsida. Då blanketten endast är tillämpbar i Sverige ska utländska anbudsgivare visa motsvarande dokumentation som intygar att denne fullgjort föreskrivna registreringar och betalningar i hemlandet. Utvärdering Referensuppdrag Minst tre genomförda uppdrag ska anges, med kontaktdata till person hos kunden. Minst ett av dessa uppdrag ska vara för statlig myndighet, gärna universitet/högskola. Beskriv uppdragen och inkludera information om version av programvara, systemmiljö, omfattning samt driftssituation. Beskriv också er organisation och hantering vid genomförande samt vilka krav som ställs på beställaren i det skedet. LiU planerar för att genomföra referenstagning den 15 mars och uppskattar att ni informerar angivna kontaktpersoner om detta. Ange totalt hur många installationer av systemet som är i drift? 12(13)

13 Organisation Beskriv den utvecklingsprocess ni har för systemet inklusive hur kvalitetssäkring sker. Bilaga Svarsbilaga 13(13)