Schaft een organisatie een saas-applicatie aan? Dan zijn er drie redenen waarom het programma van eisen (waarin beschreven waaraan de applicatie moet voldoen) zeer beknopt zou moeten zijn. Dat maakt alleen al het inkooptraject of de aanbesteding een stuk eenvoudiger.
Veel applicaties worden tegenwoordig aangeboden op basis van software-as-a-service (saas). Hierbij wordt de applicatie beschikbaar gesteld vanuit het datacenter van de leverancier en deze leverancier verzorgt alle benodigde hard- en software. Op het moment dat een organisatie zo’n saas-applicatie wil aanschaffen zijn er drie redenen waarom het programma van eisen (het pve) beknopt moet zijn.
Drie redenen
Ten eerste: een leverancier zal zeer terughoudend zijn de saas-applicatie op de gestelde eisen aan te passen. Als een ‘button’ in de applicatie groen is, is deze dus groen en niet rood en zal de leverancier deze in de regel ook niet rood maken als dat geëist wordt. Grote kans namelijk dat dan bij alle klanten het knopje rood wordt. Leveranciers zullen zo geen offerte indienen als er zaken worden gevraagd (geëist) die geen onderdeel zijn van de standaard oplossing. Organisaties moeten zich bewust zijn dat als zij kiezen een saas-applicatie daarmee ook wordt gekozen om aan te sluiten bij ‘standaard’ in de markt beschikbare oplossingen (en dus in dit voorbeeld bij een groene button). De applicatie, die vaak voor meerdere klanten een gezamenlijk platform gebruikt, zal maar beperkt aanpasbaar zijn op inhoudelijke klanteisen en het is daarmee niet mogelijk dat iedere klant een eigen oplossing krijgt. Uiteraard wordt de applicatie wel op iedere klant ‘ingericht’ maar dat is iets anders dan aangepast. Het knopje is groen en als er een rood knopje wordt gevraagd zal niet worden aangeboden. Oppassen dus voor het stellen van dit soort eisen waardoor een leverancier geen offerte zal / kan indienen.
Dan twee. Het is waarschijnlijk ook niet zo erg als het knopje groen is, de leverancier heeft er waarschijnlijk over nagedacht dat dat handig is. Ga er maar van uit dat de leverancier veel zaken rondom de applicatie beter weet dan zijn klanten. De leverancier heeft als corebusiness het leveren van de applicatie en doet dat waarschijnlijk al jaren aan een heleboel klanten. De applicatie is al jaren aangescherpt op klantvragen, is gebouwd voor een diversiteit aan klanten en bevat vaak veel meer functionaliteit dan je nodig hebt en/of voor je pve kan bedenken. Het is zo voldoende als het pve gericht is op het ‘aanstaan’ van de juiste modules binnen de applicatie (bijvoorbeeld een rapportage module) of de gewenste koppelingen maar niet op detaileisen over dat het knopje om de rapportage te starten groen moet zijn.
Aardig is om de aanschaf van bijvoorbeeld Microsoft Office in de gedachtenlijn van bovenstaande twee redenen nog eens na te gaan.
Tot slot de derde reden. Als een leverancier desalniettemin móét voldoen aan een uitgebreid en gedetailleerd pve, dan is de kans groot dat er maatwerk wordt geleverd. Maatwerk is in de regel ongewenst maar al helemaal bij saas. Vaak betekent dit dat je niet mee kan met nieuwe ontwikkelingen, dat je een uitzonderling bent in de (standaard)dienstverlenging (en -processen) van de leverancier, dat er maar weinig medewerkers bij de leverancier zijn die precies weten hoe het bij jou zit, dat koppelingen niet goed werken, et cetera. Als er toch goede redenen zijn om een maatwerk applicatie te willen zou je eigenlijk niet moeten uitgaan van saas. Saas past bij applicaties die veel organisatie gebruiken zoals een financieel pakket of hr-pakket maar niet bij maatwerkapplicaties zoals ze bijvoorbeeld gebruiken bij de belastingdienst of andere instellingen die een zeldzame dienst leveren.
Aanstaan
Het pve zou zich moeten richten op het ‘aanstaan’ van de juiste modules (vaak is de pricing per module), op ‘klantspecifieke zaken’ zoals aantallen (gelijktijdige) gebruikers of gewenste koppelingen en op zaken die moeten zijn vastgelegd om eventuele toekomstige discussies te voorkomen zoals bijvoorbeeld de verwachte beschikbaarheid, opslagcapaciteit en responstijden.
Uiteraard zullen er ook eisen moeten worden gesteld aan de eenmalige diensten om de applicatie in te richten en ‘live’ te krijgen (inclusief overzetten van huidige data en te geven trainingen) en aan de diensten als de applicatie eenmaal live is (zoals helpdesk ondersteuning, doorontwikkeling). Ook zullen er zoals in ieder inkooptraject eisen moeten worden gesteld aan de planning, de looptijd van de overeenkomst, betalingsschema’s, normen of voorschriften waar aan voldaan moet worden, en in dit geval ook een exit-clausule. Genoeg dus om wel op te nemen in de eisenlijst maar dus geen lange lijsten met alle functionele details waaronder dat groene klopje.
SaaS gaat NIET om het aanschaffen van een applicatie, het gaat om het afnemen van een dienst die geleverd wordt door software welke flexibel kan zijn als we kijken naar fenomeen van agile. Ik wil niet op de man spelen maar ik vrees dat inzichten aangaande nieuwe delivery modellen wel een rol spelen in de functie van de auteur. Als je de knop pimpelpaars wilt hebben dan leveren we dat want het gaat om wat er gebeurt als je op de knopt drukt.
Helemaal mee eens, en het aansluiten bij de standaard in de markt geldt ook voor de juridische voorwaarden. SaaS willen, maar alleen tegen Arbit- of Gibit-voorwaarden is even problematisch. Saas is een standaard dienst tegen standaard voorwaarden.