Software as a Service (SAAS) – Leidraad
Software as a Service (SAAS) – Leidraad
Dit document heeft twee doelen:
Ten eerste wil dit document een leidraad bieden voor collega’s, ook met een minder uitgebreide IT- kennis, die een Software-as-a-Service (SaaS)-contract willen afsluiten. Het claimt niet de absolute waarheid te verkondigen, maar put uit de ervaringen en lessons learned die ICTS heeft opgebouwd bij vorige aankopen.
Het document wil het doelpubliek minstens laten nadenken over de hele levenscyclus van het het Saas- contract, al van vóór de opstart van het formele aankoopproces.
Ten tweede tracht dit document het doelpubliek bewust te maken van de bredere implicaties die gepaard gaan met de aanschaf van een SAAS-product. Wanneer interactie of (hulp bij) integratie met andere KU Leuven-systemen of tools nodig is, zoals bijvoorbeeld integratie met SSO (Single Sign On), is het van cruciaal belang dat ICTS voorafgaand aan de aankoop wordt geraadpleegd. Indien dit niet gebeurt, wordt de aangekochte oplossing automatisch als een op zichzelf staand product beschouwd, en kan de business eigenaar niet uitgaan van eventuele integratie met andere KU Leuven-systemen.
Voor ondersteuning kan steeds de SaaS-circle worden gecontacteerd.
1 AANKOOPPROCES 2
1.1 Afbakenen van de scope 2
1.2 RFI – Request for information (marktonderzoek) 3
1.3 Aankoopprocedure 7
2 IMPLEMENTATIE 12
2.1 Start incrementele implementatie & aankoopprocedure op mekaar afstemmen 12
2.2 INSPANNINGEN ICTS 13
2.3 Inspanningen cloud leverancier/externe consultancy (integrator) 13
2.4 Expertise van de SAAS-oplossing in-house opbouwen 13
2.5 IT GOVERNANCE TIJDENS DE IMPLEMENTATIE 14
3 ONDERHOUD & UITBATING 15
3.1 Verantwoordelijkheden van ICTS 15
3.2 Verantwoordelijkheden van cloud leverancier, integrator of consultants 16
3.3 Verantwoordelijkheden van de business (afnemende partij) 16
4 EVALUATIE 18
4.1 Contractverlenging 18
4.2 KOST VS. BATEN 18
4.3 STATISTIEKEN 18
5 EXIT 19
5.1 Verschillende types van exitcontexten/-scenario’s 19
5.2 Fases van een exitstrategie 19
5.3 Exit maakt deel uit van de aankoop! 20
1 AANKOOPPROCES
Bij aankoopdossiers met een cloud-component is het - naast de evaluatie van de functionele componenten - minstens even belangrijk om ook de achterliggende cloud-componenten mee te evalueren. Bij een cloud-omgeving staan de gegevens niet langer op servers van KU Leuven (on- premise), maar op servers van de leverancier (of diens onderaannemers). Vaak wordt ervan uitgegaan dat de garanties die bij on-premise oplossingen door de eigen IT-organisatie worden gegeven, automatisch ook worden gegarandeerd door de cloud provider, maar dit is zeker niet altijd het geval, of niet in dezelfde mate. Vandaar de behoefte aan een vragenlijst voor cloudoplossingen.
ICTS Aankoopadvies heeft hiervoor een algemene vragenlijst ter beschikking gesteld, deze kan je onder volgende link terugvinden:
Aandachtspunten bij cloud-aankopen - ICTS (xxxxxxxx.xx)
1. 1 Afbakenen van de scope
1.1.1.1 Identificatie van de behoefte (wat hebben we nodig?)
Voor we naar de markt gaan dienen we te identificeren wat de specifieke behoefte is die we proberen in te vullen. Dit geeft ons de mogelijkheid om gericht informatie uit de markt te krijgen, zowel in eerste instantie in de RFI-fase, als later tijdens de aankoopfase.
Er zijn een aantal vragen die je je daarbij kan stellen:
Wat zijn de minimale behoefte die we willen vervullen? Welk probleem willen we oplossen?
Hebben we dit echt nodig?
Hebben we al oplossingen/tools beschikbaar die dit (gedeeltelijk) invullen?
Zijn er voorwaarden waar de oplossing moet aan voldoen? (specifieke doelgroep, uitwisselen van gegevens, gevoeligheid van data …)
Integraties met andere tools (online betaal toepassingen, Single Sign On (SSO), …)?
Wat zijn de succesfactoren die ervoor zorgen dat de behoefte vervuld wordt, of het probleem opgelost wordt?
Gaat het om een specifieke of geïsoleerde behoefte, of moet er een oplossing voor een ruimere vraag worden gezocht? (beperkt aantal specifieke gebruikers <> universiteitsbreed)
Wordt er een stabiel gebruik verwacht of zal er wisselend gebruik of groei zijn. (bvb start met een kleine groep, mogelijke uitbreiding naar een grotere groep). En, in het geval van wisselend gebruik, hoe groot zijn de verschillen in het aantal gebruikers (bvb starten kleine groep, big bang naar de volledige organisatie)
Wie zijn de gebruikers? (personeelsleden, onderzoekers, studenten,…)
Wie betaalt? Wat is het budget dat we hebben?
Willen we een deel van de kosten kunnen doorrekenen, en zoja, hebben we dan rapportering nodig op basis van bepaalde parameters of is er specifieke beheersfunctionaliteit nodig?
Hoe lang willen we een contract aangaan?
Xxxxxx er persoonsgegevens verwerkt worden?
…
1.1.1.2 Resultaat:
We weten wat we (functioneel) nodig hebben, voor wie de oplossing is, wat de (te verwachten) aantallen zijn en of we al dan niet reeds gerelateerde tools ter beschikking hebben.
1. 2 RFI – Request for information ( marktonderzoek)
De “request for information”-fase is een fase die in principe niet tot de aankoopprocedure behoort, maar die ons voldoende informatie moet geven om een goed en haalbaar lastenboek op te stellen.
Het is niet de bedoeling om al gedetailleerde antwoorden te krijgen op alle vragen, maar eerder om een goed zicht te krijgen op de mogelijkheden van de beschikbare producten in de markt en om eventuele breekpunten in een vroeg stadium te ontdekken.
LET OP: Het is belangrijk om enkel te focussen op de informatie die nodig is om te beslissen of er al dan niet een aankoopprocedure moet worden opgestart. Ga dus niet te ver, want het risico is dat je een aantal stappen opnieuw zal moeten uitvoeren.
1.2.1.1 In deze fase willen we zicht krijgen op:
De spelers en oplossingen in de markt:
o Zijn er verschillende aanbieders die voor ons een oplossing kunnen bieden?
o Dekken deze oplossingen de behoefte volledig of gedeeltelijk af?
o Waarin verschillen deze aanbieders qua functionaliteit?
o Waar worden de cloud-omgevingen gehost, en worden de persoonsgegevens verwerkt (van belang voor GDPR). Voorkeur gaat naar omgevingen en leveranciers die zich volledig op Europese bodem bevinden.
De prijs:
Tijdens de RFI-fase kunnen we al heel wat informatie inwinnen wat betreft de prijs. Hoe meer informatie we hier al naar boven kunnen krijgen, hoe duidelijker we kunnen budgetteren en over de prijs kunnen onderhandelen in de aankoopfase.
Wat zijn de elementen die prijs bepalen?:
o Aantal studenten/ aantal personeelsleden?
o Aantal transacties?
o Aantal actieve gebruikers? Aantal niet actieve/ slapende gebruikers?
o Hoeveelheid gebruikte capaciteit in de cloud, bijvoorbeeld storage?
o Hoeveelheid getransporteerde data van en naar de omgeving?
o Een combinatie van voorgaande?
o Is er een implementatie- en of migratiekost?
o Wat zijn de standaardtarieven?
o …
En hoe vertaalt de leverancier dit in zijn prijsmodel, welke prijsmodel(len) is (zijn) standaard of meest voorkomend voor dit type aankoop, en welke genieten onze voorkeur:
o Pay as you use:
Er wordt “consumptie”-gebaseerd aangerekend op basis van vastgelegde eenheidsprijzen. Hierbij is het van belang om na te gaan wat die “consumptie” juist inhoudt en wat de exacte basis is voor de eenheidsprijzen.
Dit model kan aangewezen zijn als het om een beperkte groep gebruikers en verbruik gaat. Echter, bij een grote en/of wisselende “consumptie” zal dit kosteninefficiënt zijn en mogelijk resulteren in dure en/of onvoorspelbare facturen.
Het is nuttig om na te gaan of er staffelkortingen worden aangeboden en welke de verschillende grenswaarden zijn.
o Storagekost:
De prijs wordt bepaald aan de hand van het volume van de storage dat wordt gebruikt. Ga zeker na of de storagekost upfront dient te worden betaald op basis van een “gereserveerd” volume, of deze verrekend wordt op basis van het werkelijk verbruik.
o Licenties:
Er is een vaste kost per gebruiker. Meestal zijn er verschillende licentietypes naargelang de wijze van gebruik (bvb het onderscheid tussen named en concurrent licenties). Belangrijk is om hier een zicht te krijgen op de grenzen van de verschillende types (denk hierbij aan het onderscheid tussen perpetual/aangekocht versus subscription/ huur van licenties). Dit zorgt voor een grotere voorspelbaarheid van de facturen.
Bij wisselend gebruik kan de uitlevering van licenties zorgen voor een grote verborgen administratieve kost (wie is verantwoordelijk voor de toewijzing van de licenties aan gebruikers). Ook hier is het nuttig om na te gaan of er, enerzijds, staffelkortingen worden aangeboden en welke de verschillende grenswaarden zijn, en, anderzijds, hoe de licenties door de leverancier worden verdeeld (hoe kunnen de licenties worden aangevraagd en geregistreerd? - is er een portal voor het beheer van licenties en kan de aankopende eenheid hier zelf zijn licenties beheren? - hoe makkelijk/moeilijk kunnen deze centraal en/of decentraal beheerd worden? - hoe is het rechtenbeheer geregeld (indien van toepassing)? - …).
o Campuslicenties:
Er is één vaste kost voor KU Leuven voor alle gebruikers. Deze wijze heeft de voorkeur bij oplossingen met veel (en wisselende) gebruikers. Bij dit soort oplossingen wordt de instap al van bij de aanvang gekenmerkt door een groot aantal gebruikers of door een grote “consumptie”. Het is van belang om zicht te krijgen op de contouren van de beschikbare campuslicenties (minimaal aantal gebruikers/verbruik,…).
Dit zorgt voor een zeer voorspelbare factuur, en heeft de absolute voorkeur als ons businessmodel past binnen de grenzen van de aangeboden campuslicentie.
o Er zijn op de markt nog andere prijsmodellen aanwezig. Een paar voorbeelden die reeds de revue zijn gepasseerd:
Credits: Er worden op voorhand credits aangekocht en deze worden opgebruikt naargelang het verbruik. De inschatting van het verbruik zal vrij accuraat moeten zijn, want de kans bestaat dat niet verbruikte credits vervallen en niet kunnen gerecupereerd worden.
Per datarecord: Er wordt betaald per record dat in de cloud wordt bewaard. Hier moet er goed gekeken worden of dit wel matcht met ons eigen businessmodel. De kans is bestaande dat de kost niet in verhouding staat tot het werkelijke gebruik.
Transactie-gebaseerd: De prijs wordt bepaald per volledig afgeronde transactie. Heel goed nagaan wat een transactie precies inhoudt en of dit past op het eigen businessmodel.
Op basis van een forecast van piekverbruik.
Probeer de mogelijke verborgen kosten of de beperkingen van het gebruik te identificeren:
o Worden er extra opslagkosten, dataverkeer, verbruik van bandbreedte aangerekend? Zijn er volumebeperkingen waarboven je extra moet bijbetalen?
o Worden er API-calls aangerekend?
o Dekt het prijsmodel het volledige onderhoud?
o Wordt ongebruikte functionaliteit die in de achtergrond van de oplossing draait, aangerekend?
o Wordt er gratis een test en quality omgeving voorzien of worden die ook aangerekend?
o Hoe schaalbaar is de oplossing?
Welke kosten stijgen als het verbruik toeneemt? Wat bij verbruikspieken in bepaalde periodes?
Welke kosten dalen bij een vermindering van verbruik? Is er een minimale afname?
o Probeer van de aanbieder een simulatie van de kosten te krijgen voor een bepaald scenario, dit kan helpen om alle/zoveel mogelijk parameters in kaart te brengen
Resultaat:
We weten wat de meest voorkomende prijsmodellen op de markt zijn, en we kunnen al een ruwe raming (over de verwachte looptijd van het contract) maken van de werkelijke kost op basis van ons businessmodel en van de standaard tarieven op de markt.
De cloudomgeving
o Op welke infrastructuur draait de SAAS-omgeving?
Een eigen omgeving
Een cloud platform zoals AWS of Azure?
Is er een mogelijkheid om de SAAS-oplossing in Europa te hosten?
o Welke data worden bijgehouden in de cloudomgeving? Heeft de SAAS provider hiervoor een standaard verwerkersovereenkomst?
o Voorziet de SAAS-oplossing de mogelijkheid om te koppelen met de KU Leuven authenticatie- infrastrustuur via SSO (Single Sign On) conform onze voorgeschreven standaarden? (dit is een uitsluitingscriterium).
o Laat de SAAS-leverancier toe om de toepassing gratis te testen via een tijdelijke sandbox constructie?
LET OP: een POC (Proof of Concept in een sandbox-omgeving) voor een SAAS-omgeving laat meestal wel toe om een goed beeld te krijgen van de functionele features, maar is dikwijls niet (helemaal) representatief wat de werkelijke implementatie inspanningen betreft. Bij de werkelijke implementatie gaat er vooral heel veel tijd naar het opzetten van de interfaces. Deze worden over het algemeen niet opgezet/getest in een POC.
Requirements
De requirements kunnen worden opgedeeld in functionele (hoe willen we het gebruiken, wat willen we ermee doen) en niet-functionele requirements (technologische vereisten, NFR’s – non functional requirements):
Functionele requirements:
o Deze zijn afhankelijk van het doel. Je kan vragen formuleren op basis van een WIAWIZ.
WIA: | Wanneer Ik Als | de context |
WI: | Wil Ik | de nood van de gebruiker |
Z: | Zodat | de toegevoegde waarde/doelstelling |
LET OP: Stel dat een product met modules werkt, dan is het essentieel om uit te klaren welke functionaliteit in welke modules zit. Extra modules gebruiken betekent vaak extra kosten.
Niet-functionele requirements:
o Onderstaande items kunnen worden afgetoetst, afhankelijk van de gevraagde oplossing zijn ze al dan niet relevant:
SSO (Single Sign On) volgens onze standaarden
Security volgens onze standaarden (zie checklist met vragen voor leveranciers)
Bewaren van data (afhankelijk van de oplossing)
Administratieve rollen en de mogelijkheden voor gedeeld beheer
Technische manieren van integratie, gebruik van standaarden (bijvoorbeeld LTI voor Ed- tech tools)
Mogelijkheden om de tool te customiseren, hoe wordt gegarandeerd dat customisaties ondersteund blijven?
Mogelijkheden om de tool open te stellen voor bepaalde doelgroepen/ gebruikers.
Service Level Management
Supplier Contract Management: welke componenten bepalen de prijsstructuur en hoe kunnen die (contractueel) onder controle gehouden worden?
…
o Technische en organisatorische NFR’s die af te checken zijn:
Availibility Management: Hoe wordt de beschikbaarheid van de service gegarandeerd?
Capacity Management: Hoe wordt de capaciteit van de service gegarandeerd?
Security Management: Welke veiligheidsmaatregelen worden genomen?
Service Continuity Management: Welke maatregelen zijn beschikbaar om ervoor te zorgen dat de service zo snel mogelijk hersteld wordt in geval van calamiteiten?
Technisch mechanisme voor concurrent users
Contractuele checks:
o Staan er “exotische” voorwaarden in het contract? (eventueel in deze fase al voorleggen bij de juridische dienst)
o Hoe wordt omgegaan met prijsherziening, zitten er verdoken clausules in het bestek die mogelijk nadelig kunnen zijn?
o Wat zijn de standaard betalingsvoorwaarden?
o Hoe wordt Intellectual Property (IP) contractueel verwekt? (eventueel in deze fase al voorleggen bij de juridische dienst)
o Waar worden persoonsgegevens verwerkt en is er een standaard contract voor een verwerkersovereenkomst? (eventueel in deze fase al voorleggen bij de DPO)
1.2.1.2 Resultaat van de RFI:
We weten welke oplossingen er bestaan in de markt die de behoefte (gedeeltelijk) kunnen vervullen.
We begrijpen de prijsmodellen en hebben een eerste prijsraming, we begrijpen de technologie en de functionaliteiten van de verschillende oplossingen.
We hebben alle informatie om te beslissen of we al dan niet een aankoopprocedure opstarten.
LET OP: Het is mogelijk dat de procedure stopt na de RFI. Indien blijkt dat er geen voldoende goede oplossing is voor een verantwoorde kostprijs, kan beslist worden niet te starten met een aankoopprocedure.
1. 3 Aankoopprocedure
1.3.1.1 Vastleggen van de scope of omvang van de opdracht
Op basis van de lessons learned uit de RFI, wordt de behoefte, zoals eerder vermeld, vertaald in de high level scope en afbakening van de scope die als basis dient voor de opdracht.
1.3.1.2 Raming van de opdracht en keuze van procedure
De raming is steeds gebaseerd op de duurtijd van het contract dat zal worden afgesloten, inclusief de verwachte verlengingen. Voor de meest recente drempelbedragen en de daaraan gekoppelde aankoopprocedures kan je terecht op de webstek van de aankoopdienst.
Mogelijks zal de aankoopdienst ook vragen om een procedurekeuze te verantwoorden: bijvoorbeeld in het geval van een langere duurtijd noodzakelijk is of wanneer je moet kunnen onderhandelen tijdens de aankoopprocedure, … .
1.3.1.3 Criteria voor het selecteren van de kandidaten (Selectiecriteria)
Afhankelijk van de procedure die dient te worden gevolgd, kunnen een aantal bedrijven aangeschreven worden met de meest interessante oplossingen, of zullen er selectiecriteria moeten worden opgemaakt om de juiste kandidaten te selecteren.
Selectiecriteria hebben betrekking op de competentie van het bedrijf (en dus niet op de oplossing). Vaak gebruikte parameters zijn: relevante referenties, relevante certificaten, relevante knowhow aanwezig in het bedrijf (bv.
Voldoende technische experten,…). Je zal hier minimumvoorwaarden aan moeten koppelen. Voorbeelden kunnen zijn:
Vragen naar referenties - binnen de onderwijswereld
Vragen naar referenties van - een zekere schaalgrootte
Vragen naar installaties in Europa (indien relevant)
…
1.3.1.4 Beschrijven van de requirements
Na het selecteren van de kandidaten zullen ook de eigenlijke eisen en wensen moeten uitgeschreven worden, bij voorkeur steeds met een beschrijving van de minimale voorwaarden waaraan deze moeten voldoen. Hierbij moet uiteraard ook rekening gehouden worden met de ervaringen uit de RFI.
De eisen en wensen worden bij voorkeur opgedeeld in verschillende onderdelen:
Prijsopgave
Uit de RFI zou duidelijk moeten zijn welke prijsmodellen er standaard worden gehanteerd op de markt. De voorkeur gaat uit naar een prijsmodel dat past bij ons eigen business model of bij de manier waarop wij de tool willen gaan gebruiken. Probeer hierbij de volgende zaken te beantwoorden:
o Hoeveel zal de tool gebruikt worden en door hoeveel gebruikers?
Voor universiteitsbrede tools met veel verbruik kan het nuttig zijn om op een campuslicentie aan te sturen.
Voor nichetools met laag verbruik kan het nuttig zijn om consumptie-gebaseerd te werken.
o Is dit verbruik stabiel in de tijd (korte termijn – lange termijn)?
Start je bijvoorbeeld met een kleine groep gebruikers en groei je naar groter verbruik op termijn, dan moet je prijsmodel mee-evolueren (zie prijsherziening). Bij gestaffelde prijzen is het belangrijk dat die contractueel vast gelegd zijn, en dat de hoeveelheden gecumuleerd worden over alle bestellingen heen en niet als individuele bestellingen beschouwd worden.
o Zijn er prijsmodellen die moeten vermeden worden?
Bv. bij een tool die weinig verbruik heeft, maar wel universiteitsbreed nodig is (veel gebruikers met sporadisch gebruik), is het te vermijden dat je per gebruiker betaalt. Het kan hier nuttiger zijn om consumptie-gebaseerd te aan te rekenen.
o Zijn er mogelijke verborgen kosten die transparant moeten worden gemaakt? Hier kunnen scenario’s met een bijhorende simulatie meer duidelijkheid scheppen.
Prijsherziening
Als je een tool hebt waarbij er over de looptijd van het contract een groot verschil zit in gebruik en/of gebruikers, is het aangewezen om te beschrijven hoe je de prijs onder controle wil houden of wil laten mee- evolueren. Er zijn verschillende manieren om dit te doen:
o Staffelkortingen: bij de offerte dient de aanbieder eenheidsprijzen op te geven voor verschillende stappen in gebruik en/of gebruikers. Bv. prijzen 0 tot 10; 11 tot 100; 101 tot 200,… gebruikers
o Maximumbedrag
o Heronderhandelingsclausule: Dit kan nuttig zijn als de evolutie niet te voorspellen is. Je start bijvoorbeeld met een kleine groep gebruikers op een consumptie-gebaseerde basis. Je hebt geen idee in welke richting dit gaat evolueren. Je stelt dus een clausule op dat, op het moment dat je een bepaalde drempel overschrijdt, je opnieuw gaat samenzitten met de aanbieder om het prijsmodel te heronderhandelen (bv. naar licentietype per gebruiker).
Functional requirements
Welke doelstellingen moet de aangekochte tool kunnen verwezenlijken:
o Beschrijf deze requirements aan de hand van doelstellingen (WIAWIZ) en de lessons learned uit de RFI.
o Besteed tevens aandacht aan hoe de doelstellingen gerealiseerd worden. Zo kan een bepaalde functionaliteit aanwezig zijn, maar bijvoorbeeld enkel op een omslachtige manier. Dit zou beoordeelbaar moeten zijn.
o Kan er een onderscheid worden gemaakt in primaire en secundaire doelstellingen dan wordt dit best opgenomen. Maak ook een onderscheid tussen “Must have” (minimale eis), ”Should have” (echte meerwaarde), “Could have” (bijkomende meerwaarde) en “Nice to have” (geen echte meerwaarde ten opzichte van de basisdoelstelling).
Let wel op met het bepalen van minimale eisen in het bestek. Dit werkt immers volgens het knock- out principe: beantwoordt de tool/oplossing niet aan de minimale eis dan moet de offerte uitgesloten worden.
Non-functional requirements (NFR)
Technische vereisten, integraties,…
1.3.1.5 Kostprijsmodel
Uit de RFI zou duidelijk moeten zijn welke de verschillende prijsmodellen zijn die beschikbaar zijn op de markt. Indien mogelijk wordt gekozen voor één eenduidig prijsmodel voor de volledige contractduur.
Wanneer dit niet mogelijk is (interessante producten met een ander prijsmodel), dan kan je de prijszetting overlaten aan de inschrijver, maar is het van belang dat je een transparante en vergelijkbare totaalprijs over de looptijd van het contract terugkrijgt. Probeer in een dergelijk geval een procedure met onderhandelingen op te starten zodat eventuele foutieve assumpties bij de prijsberekening bijgesteld kunnen worden.
Zorg ervoor dat alle mogelijke verborgen kosten worden benoemd.
1.3.1.6 Andere contractuele voorwaarden Andere contractuele voorwaarden kunnen zijn:
Voorwaarden voor technische ondersteuning
Eventuele SLA’s en supportcontracten
Ga na of er specifieke wettelijke contractuele voorwaarden moeten vervuld worden zoals bv.:
GDPR,
… .
1.3.1.7 Vastleggen van het gunningsproces
Voor de aankoop van SAAS-producten is het aangewezen om steeds te werken met onderhandelingen tijdens het aankoopproces. Enkele redenen hiervoor:
De prijsmodellen van verschillende leveranciers zijn niet makkelijk te vergelijken. Vaak is dit pas mogelijk na bijstellen van verschillende offertes.
Het toepassingsgebied van het product kan niet duidelijk afgebakend worden. Wel opletten met functionaliteiten die niet in lijn liggen met de oorspronkelijke doelstellingen om een bepaalde aankoopprocedure op te starten. Blijf waken over de scope en de essentie van het product.
De specificaties voor het product kunnen niet eenduidig neergeschreven worden.
Het is niet enkel belangrijk of een bepaalde functionaliteit aanwezig is, maar ook hoe deze wordt uitgevoerd.
Dit wordt mogelijks pas duidelijk na een demo en verdere toelichting.
De standaard plaatsingsprocedures (openbare en niet openbare aankoopprocedures) laten geen onderhandelingen met de leveranciers toe tijdens het verloop van de procedure. Uitzonderingen zijn echter mogelijk:
Onder de drempel van Europese publicatie laat de wetgeving bepaalde aankoopprocedures toe met onderhandelingen.
Voor aankopen met een raming boven de Europese drempel, laat de wetgeving onderhandelingen toe in specifieke gevallen. In deze gevallen moet de aanvrager een procedurekeuze met bijhorende motivering opstellen waarom onderhandelingen strikt noodzakelijk zijn. Dit gebeurt best in samenspraak met de aankoopdienst. Zij beslissen bovendien of de procedurekeuze al dan niet door de regeringscommissaris dient goedgekeurd te worden.
Wanneer een bepaald product technisch uniek is, kan je een procedure met onderhandelingen opstarten met slechts één leverancier. Deze technische uniciteit houdt in dat het product één of meerdere cruciale functionaliteiten bevat die niet terug te vinden zijn bij andere producten op de markt. In dat geval moet er een procedurekeuze opgesteld worden waarin de technisch uniciteit beschreven en gemotiveerd wordt.
Meer uitleg over de verschillende procedures en de bijhorende drempels kan je terugvinden op de webpagina van de aankoopdienst: xxxxx://xxxxx.xxxxxxxx.xx/xx/xxxxxxx/xxxxxxxxxxxxx/xxxxxxxxxx/xxxxxxxxx_xxxxx.xxxx
1.3.1.8 Beoordelingscriteria (Gunningscriteria), weging en keuze van de oplossing
De meest gebruikte gunningscriteria en manieren van beoordelen zijn:
Prijs
Best practice is hier om de verschillende offertes te vergelijken op basis van de totale kostprijs over de looptijd van het contract. De meest voorkomende formule is dat de goedkoopste het maximum van de punten krijgt, en de andere in verhouding punten krijgen ten opzicht van het dubbele van de prijs van de goedkoopste. Een offerte die dubbel zo duur of meer is zal dus 0 punten krijgen.
Functionele waarde
Op basis van de doelstellingen (WIAWIZ) kan de beoordeling van de functionele waarde in kleinere subcriteria worden opgedeeld, waarbij verschillende doelstellingen logisch worden geclusterd en gewogen ten opzichte van elkaar.
De meest voor de hand liggende manier van beoordelen gaat via een schaal die werkt met verschillende logische en cumulatieve stappen. Als conceptueel voorbeeld kan onderstaande dienen, waarbij de stappen concreet kunnen worden ingevuld naar gelang de aankoop:
Beoordeling | Waarde (van 0- max) | |
1 | De oplossing beantwoordt louter aan de gestelde minimale eis | 0% van de punten |
2 | De oplossing biedt een minimale meerwaarde tov de gestelde minimale eis | 25% van de punten |
3 | De oplossing biedt een meerwaarde tov de gestelde minimale eis | 50% van de punten |
4 | De oplossing biedt een grote meerwaarde tov de gestelde minimale eis | 75% van de punten |
5 | Ideale situatie voor de gestelde functionele doelstelling | 100% van de punten |
Let wel, dat je telkens ook zal moeten motiveren waarom je een bepaalde score geeft. Hierbij kan het eerder gemaakte onderscheid tussen “Must have” (minimale eis), ”Should have” (echte meerwaarde), “Could have” (bijkomende meerwaarde) en “Nice to have” (geen echte meerwaarde ten opzichte van de basisdoelstelling) nuttig blijken bij de motivering.
Technische waarde
Voor technische waarde ga je op een gelijkaardige manier aan de slag op basis van je Non Functional Requirements. Zaken die binair zijn (aanwezig of niet) en die je niet verder kan beoordelen neem je enkel op als minimale eis en beoordeel je verder niet in het gunningscriterium.
Andere minder voorkomende gunningscriteria:
o SLA en supportcontract
o Plan van aanpak implementatie
o Implementatietijd
o …
Weging tussen de criteria
Maak zelf de afweging welke criteria het meest en het minst doorwegen bij de keuze voor de oplossing en geef deze dan in verhouding een maximale score. De totaalsom van de maximale waardes van de verschillende criteria is normaal gezien 100.
De prijs zal steeds een belangrijk deel van de beoordeling zijn.
Keuze van de oplossing
De aanbieder met de oplossing die beantwoordt aan alle minimale eisen en uiteindelijk het hoogst scoort ten opzichte van de anderen zal de opdracht gegund krijgen.
Input
Het is belangrijk om input van de (hoofd)gebruikers te verzamelen bij het bepalen van de criteria en de eventuele weging, maar hou zelf de pen vast. Denk kritisch na over de mogelijk gevolgen van de evaluatie van de criteria. Het kan tevens nuttig zijn om een simulatie van de beoordeling te maken als finale toets.
1.3.1.9 Afsluiten van het contract
Het afsluiten van het contract is de laatste stap in de aankoopprocedure.
Gunningsbeslissing
De deelnemende leveranciers worden op de hoogte gebracht van de definitieve gunningsbeslissing. Deze beslissing wordt gemotiveerd door het bijhorende gunningsverslag mee te sturen naar de leveranciers. De gunningsverslag is de schriftelijke weergave van het volledige verloop van de procedure. Hierin moeten ook duidelijk de gemotiveerde scores op de gunningscriteria opgenomen worden.
Xxxxxxxxxxxx
Na de mededeling van de gunningsbeslissing, volgt een periode van 15 kalenderdagen waarbinnen de aangeschreven leveranciers de gunning kunnen aanvechten.
Contractperiode
Na afloop van de wachttermijn kan overgegaan worden tot het afsluiten van het contract. Dit resulteert in een contract met bijhorende contractperiode in SAP. Belangrijk is om al tijdens de aankoopprocedure af te stemmen met de leverancier over de volledige administratieve opvolging van het contract om discussies bij de start te vermijden
o Facturatie
Omvang initiële bestelling (bijvoorbeeld start met beperkt aantal licenties)
Frequentie van facturatie
Na ontvangst van bestelbon of op afroep van het raamcontract met een ATB (bijvoorbeeld voor consultancy facturen)
…
2 IMPLEMENTATIE
Wanneer de SAAS-oplossing is aangekocht is er bijna altijd een implementatie nodig. De implementatie tijd/kost kan uiteraard sterk verschillen afhankelijk van het product. Zeker wanneer er interfaces met andere software moeten opgezet worden, zijn er enkele belangrijke aandachtspunten. Aangezien er bij SAAS-producten bijna altijd betaald moet worden van zodra de software beschikbaar is, moet er hier ook rekening mee gehouden worden bij het inplannen van de implementatie.
2. 1
Start incrementele implementatie & aankoopprocedure op mekaar
afstemmen
SAAS-oplossingen zijn kostelijk en, in het geval van een globale gebruikskost, te duur om na contractaanvang maanden ‘in de kast’ te blijven liggen. Het is daarom belangrijk dat de start van de implementatie en de aankoopprocedure goed op mekaar zijn afgestemd, zodat de uitrol kan gestart worden zodra de aangekochte licenties beschikbaar zijn.
Bijkomende voorwaarde is dat de noodzakelijke features voor implementatie gevisualiseerd worden in de kanban- borden van de betrokken teams, geprioriteerd worden binnen de betrokken portfolio prioriteringsoverlegorganen en concreet ingepland worden binnen de betrokken teams. Eventueel kan de capaciteit van de betrokken teams verhoogd worden via consultancy.
Ook aan de kant van de business moet er genoeg capaciteit zijn om het implementatieplan te ondersteunen. Bij het eerste ‘echte’ gebruik zullen er onvermijdelijk tal van vragen opduiken die tijdens een eventuele Proof of Concept in de aankoopfase onder de radar zijn gebleven. Het ontbreken van capaciteit bij ICTS of bij de business om met deze vragen om te gaan, kan een goede reden zijn om de aankoop uit te stellen, of om de termijn van de licenties pas te laten aanvangen enige tijd na de aankoop.
De vereiste om de implementatie af te stemmen op het aankoopproces betekent uiteraard niet dat die implementatie volgens een ‘big bang’-strategie moet gebeuren van zodra de licenties geldig zijn. Het implementatieproces verloopt bij voorkeur incrementeel. Daarbij onderscheiden we verschillende mogelijke fases, die niet noodzakelijk allen aanwezig zijn:
Trial-licentie: het is een optie om de geldigheidstermijn van de aangekochte licenties pas enige tijd na het afronden van de aankoop te laten starten. Dit kan bijvoorbeeld zijn omwille van synchronisatie met het academiejaar of omdat de implementatieplanning nog onvoldoende gepland gebruik voorziet om al licentiekosten te verantwoorden. Soms kan een leverancier dan toch al vooraf (gratis of tegen beperkte kostprijs) een zeer beperkt gebruik van een trial-licentie toestaan. Dit geeft als voordeel dat enkele geselecteerde gebruikers al een eerste keer het product kunnen uitproberen, zonder grote kost. Dit kan nog in het kader van een sandbox of proof of concept zijn.
Verkenningsfase: een mogelijke eerste fase van de implementatie van de aangekochte licenties, waarbij een selecte groep gebruikers het product in gebruik neemt voor operationele doeleinden. ‘Verkenning’ duidt er hierbij op dat zij dit doen met nabije ondersteuning en opvolging van enkele interne productexperten, die samen met hen het product ontdekken. De gebruikers zijn zich bewust van deze trade-off: de risico’s van een nieuw product, zonder bestaand ondersteuningsmateriaal, in ruil voor vrij exclusieve ondersteuning. Idealiter zijn deze gebruikers voortrekkers die graag met het product aan de slag willen als pioniers of ‘verkenners’.
Pilootfase: op basis van de opgedane kennis in een eventuele verkenningsfase, zijn de ondersteuningsmogelijkheden al iets groter. De interne productexperten kennen het product al beter en kunnen voor specifieke use cases en functionaliteiten al ondersteuning op basis van ervaring aanbieden. Op basis van deze focus en eventuele nood, wordt het profiel voor mogelijke ‘piloten’ opgesteld. Deze groep kan groter zijn dan de groep van verkenners en wordt al van op iets meer afstand ondersteund, met al een eerste aanzet aan ondersteuningsmateriaal of minstens meer kennis van zaken dan tijdens de verkenningsfase. De interne productexperten zijn bij de piloten niet meer aan hun proefstuk toe.
Implementatiefase: in deze fase staat het ondersteuningsmateriaal en de kennis van de ondersteunende teams op punt om het product volwaardig te ondersteunen. Een implementatiefase is een mogelijke incrementele stap waarbij we ons nog steeds beperken tot een subset van gebruikers en/of functionaliteiten alvorens het product ‘volledig’ uit te rollen.
Brede uitrol: in deze fase krijgen alle potentiële gebruikers toegang tot het product en worden alle beoogde use cases en functionaliteiten ondersteund.
2. 2 Inspanningen ICTS
Bij de keuze van een product is het belangrijk om te evalueren hoeveel implementatie inspanningen de teams van ICTS zelf gaan moeten leveren. Vooral in de gevallen waar een integratie van de SAAS-oplossing met onze bestaande infrastructuur nodig is (bv. voor data en/ of user provisioning, identificatie, authenticatie, …), gaan de ICTS- infrastructuurteams bij de implementatie betrokken worden, om de connectiviteit te controleren/ te verzekeren.
Voorbeelden voor een koppeling zijn:
de e-mail koppeling
de koppeling tussen het ontwikkelplatform SAP Analytics Cloud (SAC) en onze Business Warehouse of Business Intelligence omgeving
of ook de koppeling tussen Blackboard en ons Learning Management System (LMS).
De complexiteit zal o.a. afhangen van het aantal schakels tussen de SAAS-oplossing en onze bronsystemen, onderstaand enkele voorbeelden:
TimeEdit – Qixium – PO – SAP SLcM
Hivebrite – PO – SAP CRM
iRaiser – SFTP-server – SAP CRM/FI
Afhankelijk van de SAAS-oplossing kunnen er uiteraard ook nog andere ICTS-teams betrokken worden en zal er input van de business nodig zijn. Zoals in 3.1 al beschreven, moet er ook aan de kant van de business genoeg capaciteit zijn om het implementatieplan te ondersteunen en moeten ze hen engagement geven qua tijdsbesteding. Voor ons is het eveneens noodzakelijk om een overzicht te krijgen van de workload die de implementatie met zich meebrengt en te evalueren of het nodig is om externe consultancy bij de implementatie te betrekken. Dit moet vervolgens ook in TFS zichtbaar zijn en geprioriteerd worden binnen de betrokken teams.
2. 3 Inspanningen cloud leverancier/ externe consultancy ( integrator)
Voor de implementatie doet de SAAS-leverancier beroep op óf eigen consultants óf op integratoren, die de expertise via hun consultants aanbieden.
Om een goede samenwerking met deze consultants te garanderen, leert de ervaring ons dat het wenselijk is om één of meerdere expert consultants tijdelijk toe te voegen aan het ICTS-team dat meewerkt aan de implementatie. Op die manier worden ze volledig ingeschakeld in de cadans en in de rituelen van het team.
Deze aanpak vereist budgettair een LnA aanpak, waarbij er vertrokken wordt vanuit een richtbudget voor implementatie, dat wordt opgevraagd in het bestek en aan een reality check wordt onderworpen tijdens de onderhandelingen. Dit houdt in dat we als ICTS zelf de coördinatie in de hand houden en de consultants inzetten via een time & material overeenkomst (timesheeten, geen fixed price).
Belangrijke vraag is ook of er initiële opleidingen worden voorzien. In de implementatiefase is er vaak intern nog niet voldoende kennis/capaciteit om zelf de opleidingen te geven.
Voorbeelden:
Econocom voor Ivanti
Capgemini bij CBI voor de POC SAC
Canguru bij SAP CRM voor Hivebrite
TimeEdit consultants voor de implementatie van TimeEdit
UI-Path consultant voor de POC en de opzet van de eerste use case
I-Raiser consultant voor de eerste configuratie van het platform
VONQ consultant voor de interface met vacature databank KU Leuven
Mobility Online consultant voor de initiële opzet en de integratie met SAP SLcM
2. 4 Expertise van de SAAS-oplossing in- house opbouwen
Voor de SAAS-oplossingen die ICTS aankoopt, is het de bedoeling dat de expertise binnen ICTS wordt opgebouwd, in plaats van hiervoor afhankelijk te blijven van de leverancier of een derde partij. Dit betreft zowel de functionele features als de integratiecomponenten. In het geval er een Proof of Concept is doorlopen kan deze kennis al deels vóór de implementatiefase worden opgebouwd. Deze kennis kan dan direct worden aangewend voor het maken van implementatiekeuzes, het opstellen van documentatie of het voorzien van opleidingen. Net zoals de implementatie zelf, zal het opbouwen van deze kennis incrementeel verlopen. ICTS is steeds eindverantwoordelijke voor de implementatie, dus de kennis over de integratie of customisatie zal typisch bij ICTS liggen.
De kennis kan verworven worden door:
Mee te draaien met de consultant van de leverancier tijdens de implementatie
Training te volgen bij de leverancier en/of integrator (en de know-how via train-the-trainer toegankelijk te maken voor andere ondersteuners of eindgebruikers)
In vele gevallen wordt de inhoudelijke ondersteuning aan de eindgebruikers geboden door een andere dienst (niet ICTS); het is dan ook nodig deze ondersteuners mee te betrekken bij de kennisopbouw en ook hen te betrekken in de inhoudelijke overlegmomenten met de leveranciers. Voorbeeld Hivebrite waar dienst alumni expertise heeft opgebouwd of het betrekken van het KU Leuven learning lab in het geval van onderwijskundige inhoud.
2. 5 IT governance t ijdens de implementatie
Voor de implementatie van een SAAS-oplossing geldt de algemene IT governance die we ook voor andere initiatieven hanteren. Het is uiteraard wel de bedoeling dat de implementatie features van een SAAS-oplossing hoge prioriteit krijgen zodat er snel toegevoegde waarde kan geleverd worden van zodra de licentiekosten beginnen te lopen. Het is de taak van de ICTS om de betrokken PPO hier bewust van te maken (voor initiateven met veel toegevoegde waarde is dit meestal geen probleem).
Ook de consultants en de project/contract manager van de SAAS-leverancier of van de integrator worden maximaal mee ingeschakeld in de algemene IT governance, bij voorkeur vanuit het team waarvoor de consultants werken tijdens de implementatie. De basis zijn de 10 weken cadans, de focus & flow principes, het TFS bord en de LnA rituelen van het team.
(x)-Daily standup
Sprint planning
Sprint review
PP planning
PP review
De ervaring leert ons dat de meeste leveranciers toch nog steeds nood hebben aan een (x)-maandelijkse stuurgroep tussen hun contract management en ons management team. Met onze IT governance en de 10 wekelijkse cadans beschikken we wel over een aanpak die dit soort stuurgroepen heel lean kan houden, waardoor de tijdsbesteding en de rapportering tot een minimum kunnen beperkt worden. Hierdoor vermijden we extra coördinatie inspanningen langs de kant van ICTS en maken we geen onnodige kosten door de tijdsbesteding van dure project/contract management profielen tot een minimum te beperken.
Het is belangrijk de primaire use cases te bewaken (tijdens implementatiefase niet te ver afwijken van MVP). Extra use cases kunnen leiden tot extra kosten, om deze te implementeren moet nagegaan worden of het budget hiervoor voorhanden is. Eventueel moeten hiervoor met de gebruikers afspraken worden gemaakt.
3 ONDERHOUD & UITBATING
Tijdens de uitbatingsfase, het gebruik van de omgeving, is het nog meer dan bij een on-premise oplossing nodig om bij elke aanpassing de impact ervan na te gaan:
- Heeft deze aanpassing een effect op de kostprijs van de oplossing?
- Ligt de aanpassing in lijn met de oorspronkelijke use-case?
- Wordt door deze oplossing meer informatie naar de cloud gebracht, en is dit in lijn met de GDPR afspraken?
- Stretchen we de oplossing niet te veel, zijn we nog in lijn met wat de leverancier voor ogen heeft?
- …
3. 1 Verantwoordelijkheden van ICTS
Tijdens de uitbatingsfase kunnen volgende taken typisch de verantwoordelijkheid van ICTS zijn:
Periodiek overleg met de account manager (bvb tweewekelijks)
o Regelmatig de vinger aan de pols houden ivm alle lopende zaken is noodzakelijk om voldoende proactief te handelen.
Technische problemen melden
o Typisch zal bug fixing op onze vraag door de leverancier moeten gebeuren.
Escalatie van issues
o Aanslepende problemen moeten tot bij of indien nodig voorbij de accountmanager gerapporteerd worden om een doorbraak te forceren wanneer noodzakelijk.
Product inspraak
o Specifieke feature requests voor nieuwe functionaliteit aanvragen of hogere prioriteit geven.
o Strategie zal verschillen naargelang de grootte van de leverancier en de relevante waarde die wij als klant voor hem hebben.
Helpdesk
o Eerste- en tweedelijnssupport voor het product wordt vaak door ICTS opgevangen.
Up to date blijven over product
o Bvb roadmap sessie of specifieke workshop of training volgen.
Gebruik monitoren
o Typisch zal het gebruik contractueel gelimiteerd zijn (bvb aantal gebruikers, storage, hoeveelheid afgenomen services,…). We willen dit gebruik monitoren om niet ongewenst limieten te overschrijden, noch te veel te betalen voor weinig effectief gebruik.
SLA’s monitoren
o Bvb uptime. Gezien de belangrijke contractuele rol van SLA’s, is opvolging logisch.
KPI’s monitoren
o We willen opvolgen hoe succesvol het gebruik van het product is in het bereiken van de doelstellingen die we ermee voor ogen hebben.
Contact met andere klanten van leverancier
o Bvb een user group van andere onderwijsinstellingen, onafhankelijk van de leverancier, kan nuttig zijn ter inspiratie, om gezamenlijke bezorgdheden aan te kaarten en meer slagkracht te hebben bij de leverancier.
Interne marketing
o Wanneer een wijdverbreid gebruik een doelstelling is, kan er ‘campagne’ gevoerd worden om het doelpubliek kennis te laten met de nieuwe oplossing en de voordelen ervan te promoten.
Heronderhandeling/vernieuwing contracten (management/aankoop)
o Typisch zal een contract met de leverancier een periode van enkele (drie tot vier) jaren afdekken. Tijdens die jaren kan er veel veranderen op gebied van gebruiksvolume, aangeboden en afgenomen functionaliteit, relevante use cases… Wanneer het nieuwe contract afgesloten moet worden, moet alle relevante informatie duidelijk opgelijst zijn om een gunstig nieuw contract te kunnen onderhandelen.
3. 2 Verantwoordelijkheden van cloud leverancier, integrator of consultants
Customer support
o In geval van een goede customer support, worden we echt geholpen bij het indienen van een ‘ticket’, versus een service waarbij de leverancier zo snel mogelijk van de vraag af wil zijn.
Bugfixing
o Een kwalitatieve leverancier zal eerlijk en open zijn over mogelijke bugs en op een verantwoordelijke manier een fix voorzien. Wanneer een product fix op zich laat wachten, zal de leverancier een workaround voorzien.
Training
o Zeker na aankoop van een nieuw product zal een leverancier, integrator of consultant opleiding voorzien om het product te leren kennen en gebruiken. Dit kan ook later van toepassing zijn in geval van updates aan het product, uitbreiding van de afgenomen services, diepgaandere specialisatie,… Eventueel zit een vast opleidingsaanbod (bvb 1 training per semester) van meet af aan in het contract.
Accountmanagement
o Typisch voorziet de leverancier een contactpersoon die onze account opvolgt. Een goede accountmanager fungeert als onze stem binnen het bedrijf van de leverancier en is betrokken, bereikbaar en verantwoordelijk. Een vast periodiek overleg (bvb 2-wekelijks) om de algemene stand van zaken te bespreken, is gebruikelijk.
Documentatie
o Zeker voor technische documentatie (vb API) is het noodzakelijk dat de leverancier kwalitatieve documentatie voorziet. Voor gebruikersdocumentatie zullen we vermoedelijk voor bepaalde specifieke use cases onze eigen documentatie voorzien, maar blijft het handig om terug te kunnen vallen op de basisdocumentatie van de leverancier.
Rapportering
o De leverancier zal periodiek (bvb maandelijks) overzichtelijke rapportering voorzien van ons gebruik van de services (gebruikersaantallen, storage,…). Meer algemeen zal de leverancier de data voorzien die benodigd zijn om onze kwantitatieve KPI’s te berekenen.
Customer services
o Wanneer nodig zal de leverancier, integrator of consultant (eventueel betaalde) services voorzien om ons te helpen bij een specifieke problematiek die niet onder de standaard customer support valt.
3. 3 Verantwoordelijkheden van de business (afnemende partij)
Bij het onderhoud van een SAAS-product dragen zowel de business als ICTS specifieke verantwoordelijkheden. Een effectieve samenwerking tussen deze twee entiteiten is van cruciaal belang om ervoor te zorgen dat het SAAS-product optimaal blijft functioneren en aan de behoeften van de organisatie blijft voldoen.
De business moet de zakelijke vereisten evalueren en verfijnen, om ervoor te zorgen dat het SAAS-product nog steeds aansluit bij de strategische doelen van de organisatie. Dit kan het identificeren van nieuwe behoeften en functionaliteiten omvatten, bv. op basis van gebruikersfeedback. Deze feedback kan betrekking hebben op gebruikerservaring, nieuwe vereisten of eventuele problemen die zich voordoen tijdens het gebruik van het SAAS- product.
Het succesvol integreren van systemen binnen het IT-landschap vereist nauwe samenwerking tussen de business en ICTS. Het is essentieel dat de business zich afstemt met ICTS om een goede inzicht te krijgen in de systeemarchitectuur. Dit overzicht stelt hen in staat om de impact van uitbreidingen of wijzigingen beter te kunnen inschatten. Zelfs bij het aankopen van een SAAS-product zonder directe betrokkenheid van ICTS, moet de business op zijn minst contact opnemen met ICTS om af te stemmen en mogelijke implicaties te bespreken.
De business moet zich bewust zijn van contractuele beperkingen, vooral met betrekking tot het prijsmodel. Als er een limiet is ingesteld op het aantal licenties/gebruikers, is het van essentieel belang ervoor te zorgen dat deze limiet niet wordt overschreden. Bovendien moet de business zich bewust zijn van eventuele extra kosten die kunnen ontstaan als gevolg van het overschrijden van het toegewezen aantal gebruikers. Enkele voorbeelden hiervoor zijn:
Aantal concurrent users in Ivanti
Hoeveelheid videomateriaal in Kaltura
Aantal admin-gebruikers in Hivebrite
Het beheer van licenties is een gedeelde verantwoordelijkheid van zowel de business als IT. Dit houdt in dat ervoor gezorgd moet worden dat eindgebruikers de correcte licenties ontvangen en dat, indien er in eerste instantie gratis licenties zijn gebruikt voor het testen van de SAAS-oplossing, er wordt overgeschakeld naar de geldige licenties.
De business moet in staat zijn om een eerstelijns helpdeskfunctie te bieden om gebruikers te ondersteunen bij basisproblemen en vragen met betrekking tot het SAAS-product.
De business moet opleidingen voor eindgebruikers voorzien, mogelijk volgens het "train-the-trainer" principe, om ervoor te zorgen dat medewerkers effectief gebruik kunnen maken van de SAAS-oplossing.
4 EVALUATIE
Wanneer een SAAS-oplossing gedurende een langere periode productief gebruikt is, of wanneer er opnieuw onderhandeld moet worden met de leverancier voor een contractverlenging, is het een goed moment om een evaluatie te maken. In deze evaluatie kan er zowel gekeken worden in welke mate de doelen uit de aanbesteding behaald zijn, als in hoeverre de voorafgaandelijke prijsinschatting afwijkt van de uiteindelijke kostprijs.
4. 1 Contractverlenging
Zowel wanneer een contract stilzwijgend verlengd wordt, als wanneer er opnieuw onderhandeld moet worden met de leverancier, is het nuttig om even tijd te nemen om het SAAS-product te evalueren. Zowel vanuit ICTS als vanuit de business die het product gebruikt, moet er kritisch gekeken worden of het wenselijk is om het contract te verlengen.
4. 2 Kost vs. baten
Bij de evaluatie van het SAAS-product moet er steeds gekeken worden of de toegevoegde waarde van het product nog steeds in verhouding is met de totale kostprijs. Doorheen de tijd kunnen er namelijk verschillende factoren gewijzigd zijn die dit evenwicht beïnvloeden:
Wordt de SAAS-oplossing nog voldoende gebruikt om de gemaakte kosten te verantwoorden?
Zijn er ondertussen andere alternatieven om aan de vooropgestelde doelen te voldoen? (zowel intern ontwikkeld als op de markt)
Is de totale kostprijs van het SAAS-product niet onverwacht gestegen? (bvb door verborgen kosten in het prijsmodel)
Zijn de vooropgestelde noden nog steeds dezelfde of is uit het gebruik van het product gebleken dat er eigenlijk andere noden zijn?
Hoeveel groeipotentieel heeft het gebruik van de SAAS-oplossing nog?
4. 3 Statistieken
Om de evaluatie oefening transparant te kunnen uitvoeren, is het belangrijk dat de juiste cijfers beschikbaar zijn. Naast de totale kostprijs van de SAAS-oplossing moet er ook voldoende informatie beschikbaar zijn over het gebruik van het SAAS-product. Aangezien dit sterk kan verschillen tussen verschillende SAAS-oplossingen, is het dus nuttig om op voorhand na te denken over de KPI’s die het gebruik van de oplossing vertalen, en deze KPI’s doorheen de tijd op te volgen en bij te houden. Wanneer je de KPI’s goed bijhoudt kan je makkelijker rapporten maken van bvb het gebruikersverloop, aantal transacties, aantal data objecten, gebruik van API’s, … .
5 EXIT
In de vorige hoofdstukken hebben wij het over de weg naar een SAAS-oplossing, maar in sommige gevallen wil je er ook terug uit. Mogelijke scenario’s om een SAAS-contract op te zeggen kunnen zijn:
je hebt grote beveiligingsrisico’s geindentificeerd,
prijsveranderingen/-stijging,
je bent ontevreden over de service van de provider,
je provider verandert van eigenaar en/of strategie,
je provider investeert niet in nieuwe innovaties, ontwikkelingen blijven liggen,
je provider verandert de service of stopt ermee,
…
In dit soort situaties is het belangrijk dat je voorbereid bent met een SAAS-exitstrategie. Onderstaand geven wij aandachtspunten mee die als input voor je exitstrategie kunnen dienen.
5. 1 Verschillende types van exitcontexten/- scenario’ s
Op basis van het type SAAS-oplossing zijn er verschillende types van exitcontexten/-scenario’s mogelijk:
1. Een SAAS-oplossing fungeert als een transactionele toepassing, wat betekent dat het gericht is op het vastleggen, verwerken en beheren van transacties. Specifiek omvat dit de overstap van de ene transactionele toepassing naar een nieuwe, zoals bijvoorbeeld Hivebrite, waarbij transacties in real-time worden geregistreerd, verwerkt en beheerd.
2. Een SAAS-oplossing dient als een ontwikkelplatform, zoals bijvoorbeeld de SAP Analytics Cloud (SAC). In dit geval leest SAC in real-time data uit een bronsysteem uit, zoals het SAP Business Warehouse (BW), via een live- connectie. Rapporten en dashboards worden vervolgens door gebruikers binnen SAC ontwikkeld, waarbij de gegevens in ons eigen on-premise systeem blijven opgeslagen en bij een eventuele exit niet verloren zullen gaan. Het is vooral belangrijk om rekening te houden met de ontwikkelingen die gebruikers binnen SAC hebben gemaakt.
5. 2 Fases van een exitstrategie
Een exitstrategie kan je opsplitsen in verschillende fases, bv. :
1. Preparation / Voorbereiding:
Analyseer de situatie, welke scenario’s zijn mogelijk en kunnen tot een exit leiden? Wanneer en hoe zal je uiteindelijk tot een besluitvorming over gaan? Indien mogelijk doe je deze voorbereiding al voor of tijdens de aankoopfase. Bij de keuze van een SAAS-oplossing moet de beslissing ook afhankelijk gemaakt worden van de mate waarin een toepassing migreerbaar is. Bij de onderhandelingen met de potentiële providers kan je best al navraag doen naar het datamodel van de SAAS-oplossing en dit tot op zekere hoogte analyseren. Een goede integratie tussen de SAAS-oplossing en onze backbone kan voordelig zijn bij een exit- en migratiescenario.
2. Prevention / Voorkoming:
Welke maatregelen/ acties kan je ondernemen om een exit te vermijden? Zie hiervoor ook luik 3 in dit document over de “Onderhoudsfase”.
3. Excecution / Uitvoering:
Een exit was niet te vermijden en je gaat effectief over naar het toepassen van je vooraf gedefinieerde exitstrategie (besluitvormingsprocessen, exitplannen, scripts, communicatieprocessen, …). Afhankelijk van de situatie zullen misschien niet alle onderdelen van je exitstrategie toegepast kunnen worden, maar je exitstrategie zal helpen om deze fase zo vlot als mogelijk te laten verlopen.
4. Recovery / Herstel - terug naar normaal:
In de meeste gevallen zal een SAAS-oplossing vervangen worden en de exit ofwel overlappend ofwel opvolgend gepaard gaan met de aankoop en implementatie van een andere softwaretoepassing (cloud of on- premise).
Het is belangrijk om al bij de aankoop rekening te houden met een mogelijke uitstap. De moeilijkheid ligt er wel in, dat het opvolgende product/systeem uiteraard nog niet gekend is. In veel gevallen betekent een exit een langere transitieperiode waarin dubbel gedraaid wordt op het nieuwe en het oude platform.
SAAS-oplossingen zijn in de regel te duur om deze parallel met het nieuwe product, dus als back-up, te laten draaien. In de aankoopfase kan al onderzocht worden of de provider bv. een modus aanbiedt om alleen te raadplegen, die tijdens een exit tegen een lagere kost kan gebruikt worden.
Hou er toch rekening mee dat je altijd een deel van de data/ ontwikkeling gaat verliezen. Een “collateral damage analyse” kan hierbij helpen om te kaderen welk verlies aanvaardbaar is.
Bedenk vooraf welke ‘verwijderingskosten’ er komen kijken bij een eventueel vertrek. Deze retransitiekosten bevatten niet alleen de kosten voor het tijdelijk parallel draaien van je applicaties, maar ook voor eventueel productiviteitsverlies, consultancy, kosten van dataverkeer en migratiesoftware.
5. 3 Exit maakt deel uit van de aankoop!
Een cloud exitstrategie bevat redelijk wat complexiteit, die best al tijdens de aankoopfase onderzocht wordt:
Het datamodel van verschillende cloud providers is niet uniform
De meta-data is provider-specifiek en niet altijd toegankelijk*
Automatiseringsinterfaces (CSP API’s) zijn provider-specifiek
De integraties met het platform (zoals integraties met monitoring en compliance tools) zijn provider-specifiek
*Meta-data (zoals informatie over wie bestanden heeft geraadpleegd, hoe privileges stonden ingesteld en welke gebruiker toegang heeft verschaft) wordt niet door gebruikers ge-uploaded maar door het platform gegenereerd. Deze meta-data zijn essentieel vanuit governance & compliance perspectief, maar maken mogelijks geen onderdeel uit van ‘jouw data’.