Een SaaS-oplossing kiezen via een aanbesteding? Voor veel IT-afdelingen bij gemeenten en lokale overheden voelt dat als jongleren met regels, wensen en toekomstbestendigheid. Hoe blijf je binnen de lijntjes van compliance, zonder vast te lopen in een rigide systeem dat niet helemaal past? In de blogserie ‘Op zoek naar een SaaS-oplossing voor Local Government’ delen we valkuilen én slimme strategieën om SaaS-aanbestedingen makkelijker en effectiever te maken. In deze vierde en (voorlopig) laatste blog van deze serie ga ik dieper in op eisen in de aanbesteding: houd het realiseerbaar en voorkom knelpunten.
Continuïteit van oplossing en dienstverlening
Regelmatig wordt in aanbestedingen om een Escrow-overeenkomst gevraagd. Dit past niet bij een SaaS oplossing. Escrow heeft eigenlijk alleen waarde bij de aanschaf van een on-premise applicatie. Bij een faillissement van de leverancier zou de opdrachtgever dan met de gedeponeerde broncode eventueel zelf verder kunnen werken aan of in de applicatie. Bij een SaaS-oplossing draait het systeem in een gehoste omgeving en is de opdrachtgever met de broncode niet in staat om de applicatie zelfstandig draaiende en veilig te houden. In een aanbesteding kun je uiteraard wel de vraag aan de leverancier stellen welke maatregelen er zijn genomen om de continuïteit van de oplossing en de dienstverlening zoveel mogelijk te borgen.
Certificaten en rapportages
Uiteraard wil je bij de selectie van een aanbieder bewijs hebben dat de Service Organization Controls die in gebruik zijn, geborgd zijn. Als bewijsvoering is een SOC2-rapportage daarvoor zeker geschikt als bewijsstuk, dit in plaats van bijvoorbeeld de SOC1-rapportage. Deze laatste rapportage is een uitgebreid en zeer vertrouwelijk Service Organization Control (SOC) auditrapport van een onafhankelijke externe accountant. Deze is alleen bedoeld voor financiële auditors van klanten en gebruikersorganisaties die de oplossing in de rapportageperiode hebben gebruikt. Samen met het ISO27001 certificaat is de SOC2-rapportage voldoende bewijs van externe audits van de veiligheidsmaatregelen van de leverancier.
Harde eisen aan beschikbaarheid
Wanneer je voor een SaaS oplossing kiest, onthoud dan dat er in principe geen gegevens verloren gaan bij verstoringen. Pas bij zeer grote incidenten (complete uitval van een datacenter door brand) spelen RPO (Recovery Point Objective) en RTO (Recovery Time Objective ) een rol. De RPO/RTO opvragen en beoordelen kan natuurlijk altijd, maar het is niet zinvol om eisen te stellen voor één specifieke aanbesteding. Een leverancier kan immers het standaard backup/restore proces niet voor één specifieke klant volledig afwijkend inrichten. Ook voor beschikbaarheid (buiten eventueel periodiek onderhoud) geldt dat je uit kunt gaan van marktconforme standaarden. Denk hier bijvoorbeeld aan een beschikbaarheid van rond 99,5 procent.
Strengere eisen dan de wetgeving?
De Nederlandse wetgeving, zoals bijvoorbeeld AVG, stelt duidelijke randvoorwaarden waar een oplossing aan dient te voldoen. SaaS-leveranciers hebben dit in hun producten verwerkt. Vraag je om strengere eisen dan de wet- en regelgeving? Dan betekent dit dus vaak een show-stopper. Wanneer je toch specifieke afspraken maakt is het goed om deze in de SLA (Service Level Agreement), als integraal onderdeel van de overeenkomst, vast te leggen. Besef wel dat ook hier geldt dat de SLA een standaard document is dat op de SaaS oplossing is ontwikkeld. Een afwijkende of een klantspecifieke SLA verstoort het standaard proces en de inrichting van de supportorganisatie, die jouw leverancier aan al haar klanten biedt. Het advies is om, als het enigszins mogelijk is, de standaard SLA van de leverancier te accepteren. Hetzelfde principe gaat op voor de Verwerkersovereenkomst, of de DPA (Data Processing Agreement). De standaard Verwerkersovereenkomst van de leverancier sluit naadloos aan op de geboden standaard SaaS-oplossing en processen en is onderdeel van overeenkomsten die de leverancier heeft met onderaannemers. De security en data protection processen die op deze standaard Verwerkersovereenkomst zijn gebaseerd zijn gecertificeerd (ISO27001) en worden periodiek ge-audit (SOC).
Zorg voor transparantie in de kosten
Laat ik hier maar meteen de knuppel in het hoenderhok gooien: accepteer dat er ook tijdens de implementatie kosten voor de levering van de SaaS-oplossing worden doorbelast.
Tijdens het implementatieproject (d.w.z. de configuratie/inrichting, migratie en opleiding) wordt de SaaS-oplossing reeds door de leverancier aan de aanbestedende dienst beschikbaar gesteld. Daarbij worden er door de leverancier dus ook al hosting en supportdiensten geleverd. Kortom, er wordt al een dienstverlening geleverd waar kosten aan zijn verbonden. Het is dan ook niet passend om niet voor deze geleverde dienstverlening te willen betalen. Als dat niet kan, dan komen deze kosten terug in andere posten, bijvoorbeeld in de implementatiekosten. Het alternatief is om de ingangsdatum van het SaaS-contract (en daarmee de start van de betalingsverplichting) al bij start van het implementatieproject in te laten gaan. Het belangrijkste advies is om te zorgen voor transparantie en de leverancier alle kosten inzichtelijk te laten maken, dus vanaf de start van het ter beschikking stellen van de SaaS-oplossing (vanaf de ingangsdatum van de software-overeenkomst).
Verschil tussen primaire en back-up datacenter
Wanneer je werkt met een internationale leverancier van een standaard SaaS-oplossing beschikt deze vaak over verschillende datacenters die wereldwijd en binnen de EU/EER zijn verspreid. Het is dan niet altijd mogelijk dat zowel het primaire als het back-up datacenter in Nederland staat. Kijk dus uit welke eisen je hieraan stelt. Het is zelfs veiliger als het primaire datacenter en het back-up datacenter in verschillende landen staan. Aan de eis dat privacy gevoelige data niet buiten de EU/EER gehost mag worden, is door internationale leveranciers doorgaans prima te voldoen.
Stel geen striktere eisen aan encryptie dan de norm
Ook hier een helder uitgangspunt: stel geen specifieke eisen aan encryptie/beveiliging, strikter dan internationaal erkende en marktconforme normen.
Standaard SaaS-leveranciers kunnen niet voor één klant hele specifieke encryptie of beveiligingseisen inrichten. Sluit daarom aan bij internationale normen op dit gebied en laat de leverancier vooral zelf aangeven hoe encryptie/beveiliging is ingericht en beoordeel dit.
Contracteren kun je leren
Het aangaan van een SaaS overeenkomst heeft soms net wat andere aspecten dan je wellicht gewend bent. Hierna een aantal adviezen:
- De offerte: vanwege bedrijfsinterne regels maar ook vanwege de snelheid van ontwikkelingen en innovaties in de softwaremarkt kunnen leveranciers van standaard oplossingen alleen offertes indienen met een vaste geldigheidstermijn van maximaal zes maanden. Vraag dus om een vaste geldigheidstermijn van de offerte, die bovendien niet langer is dan zes maanden na datum inschrijving.
- Initiële contractduur: vraag geen overeenkomsten uit met een initiële contractduur van meer dan vijf jaar. Gezien de huidige snelheid van innovaties is dit al een lange periode. Elke optionele verlenging moet tweezijdig worden overeengekomen.
- Indexering: accepteer de prijsindexering van de leverancier (mits deze objectief verifieerbaar is). Natuurlijk moet de wijze van indexering voor iedereen vooraf helder zijn en moet de te hanteren index objectief verifieerbaar zijn.
- Prijsmetrieken: geef je leverancier de mogelijkheid om eigen metrieken (die voor jou als opdrachtgever voorspelbaar en verifieerbaar zijn) te gebruiken in het prijsmodel. Het voorschrijven van specifieke metrieken, die niet overeenkomen met die van de leveranciers, leidt tot knelpunten.
- AVG en/of BIO: eis niet dat de oplossing zelf aan de AVG en/of BIO moet voldoen. Dit is primair een verantwoordelijkheid van de opdrachtgever en kan niet worden neergelegd bij de SaaS-leverancier. Wat wel mogelijk is, is om de opdrachtnemer te vragen dat de oplossing het mogelijk moet maken voor de opdrachtgever om aan AVG en/of BIO te voldoen. Denk hierbij aan beveiliging en/of inrichtingsmogelijkheden.
De overstap naar SaaS vraagt om doordachte aanpak
Het mag duidelijk zijn. Een SaaS-oplossing vraagt om een andere benadering bij een aanbesteding dan bij een reguliere, te ontwikkelen, applicatie. Je hebt te maken met een standaardoplossing en bijbehorende randvoorwaarden. De grootste uitdaging ligt vaak niet in de technologie, maar in de adoptie ervan. De organisatie die met deze oplossing gaat werken moet een behoorlijke aanpassing doorvoeren in de manier waarop ze werken. Een succesvolle overstap naar SaaS draait niet alleen om functionaliteit en contractvoorwaarden, maar ook om goed verandermanagement. Zorg er daarom voor dat gebruikers worden meegenomen in het proces, dat er voldoende ondersteuning is en dat de voordelen van de nieuwe werkwijze helder zijn.
Kortom, een SaaS-oplossing is meer dan een technische keuze: het is een strategische beslissing die impact heeft op de hele organisatie. Ga er bewust mee om, en leg de basis voor een soepele transitie en optimaal gebruik van de oplossing.
