SaaS-applicaties: URL, gebruikersnaam en wachtwoord: Klaar?

Deel 3: Portalen – Digitale dienstverlening

Inleiding

In het eerste blogartikel uit deze serie heb ik aandachtspunten beschreven voor de architectuur van een hybride applicatielandschap met meerdere SaaS-applicaties van verschillende leveranciers, applicaties in het eigen rekencentrum (‘on premise’) en applicaties in de ‘eigen’ cloud van de organisatie.  

Dit artikel beschrijft inrichtingsvarianten voor het ontsluiten van digitale dienstverlening met portalen in een applicatielandschap met meerdere SaaS-applicaties.

Digitale dienstverlening en portalen

Digitale dienstverlening en ‘self-service’ zijn niet meer weg te denken. Organisaties bieden klanten, inwoners , partners en medewerkers digitale dienstverlening aan via een of meerdere portalen. Klanten, inwoners, partners en medewerkers worden in het vervolg van deze blog ‘gebruikers’ genoemd.

Een portaal (of portal) is een webapplicatie, die gebruikers via internet (of bedrijfsnetwerken) toegang geeft tot functionaliteit(en) en gegevens. Voorbeelden zijn portalen voor het maken van afspraken, het aanvragen van een voorziening, inzage en beheer van eigen gegevens zoals bestellingen en facturen.

De gebruiker verdwaalt

Grotere organisaties beschikken over meerdere SaaS- en ‘on premise’ applicaties, vaak heeft iedere applicatie een eigen portaal. Gebruikers worden geconfronteerd met meerdere portalen als ze digitaal zaken met een organisatie willen doen. Voor gebruikers kan de digitale dienstverlening een complexe puzzel worden: Waar moet ik zijn? De verschillende portalen hebben een verschillende ‘look and feel’ en als het tegenzit moet een gebruiker zich meerdere keren registreren en meerdere keren inloggen. De kans dat gebruikers afhaken is aanzienlijk. Het kan hierbij om grote aantallen gaan: volgens onderzoek van het CBS beschikt 20% van de Nederlandse bevolking niet over digitale basisvaardigheden.

De organisatie verdwaalt

Organisaties ondervinden de volgende nadelen van meerdere portalen:

• Imago en perceptie van de organisatie: Gebruikers zullen de organisatie niet snel associëren met kernwaarden als toegankelijk, transparant en vertrouwen.
• Geen eenduidige presentatie: Het risico ontstaat dat de ‘presentatie’ van de organisatie versnipperd wordt: de verschillende portalen zien er net iets anders uit, er zijn meerdere digitale ‘ingangen’ etc.
• Het klantbeeld raakt versnipperd over meerdere applicaties.
  Aanvullende maatregelen zijn vereist voor een integraal beeld over de klant en over de interactie van de klant met de organisatie.
• De complexiteit van het beheer neemt toe door duplicatie van functionaliteit (o.a. portaal, formulieren) en gegevens.

Inrichtingsvarianten en keuzes

Organisaties hebben de keuze uit de volgende inrichtingsvarianten:

1. Meerdere portalen.
2. Een toegangsportaal.
3. Een portaal voor alle applicaties.

Meerdere portalen

De organisatie maakt gebruik van meerdere portalen voor interactie met gebruikers. Ieder portaal ontsluit één SaaS- of ‘on-premise’ applicatie, iedere applicatie beschikt over een eigen portaal (zie figuur 1).

Deze variant past goed als:

• Het merendeel van de gebruikers gebruik maakt van één portaal en er is weinig overlap tussen de verschillende gebruikersgroepen. Voorbeelden:
  • Aparte portalen voor klanten, ketenpartners en leveranciers.
  • Aparte portalen voor het aanvragen van subsidie, het aanvragen van een uitkering in het sociaal domein, of voor lokale belastingen.
• Het aantal portalen is beperkt.
• De gebruiksfrequentie is laag: één of enkele keren per jaar is minder ‘vervelend’ dan frequent gebruik.

De voordelen zijn:

• Het portaal ontsluit met standaard functionaliteit de achterliggende applicatie.
• De functionaliteit van de applicatie is vrijwel direct beschikbaar voor de gebruikers.
• Geen vraagstukken op het gebied van maatwerk of integratie (koppelingen tussen applicaties en portalen).

De nadelen zijn geschetst in de voorafgaande paragrafen.

Een toegangsportaal

Een ‘Toegangsportaal’ is een variant op het model met meerdere portalen. De organisatie richt een ‘Toegangsportaal’ zodat één ingang voor de digitale dienstverlening van een organisatie ontstaat.

Gebruikers krijgen via het toegangsportaal toegang tot de verschillende portalen van de applicaties (zie figuur 2).

Deze variant kan toegepast worden als er significante overlap tussen gebruikersgroepen is.

Een voorbeeld is een gemeenteportaal waar gebruikers toegang krijgen tot de dienstverlening van de gemeente:

• Een afspraak maken voor aanvragen rijbewijs of identiteitsbewijs.
• Een vergunning aanvragen.
• Een uitkering aanvragen in het sociaal domein.
• Een WMO-voorziening aanvragen.
• Lokale belastingen.
• Meldingen openbare ruimte.
• Het toegangsportaal beschikt over functionaliteit voor her verlenen van toegang van gebruikers (authenticatie en autorisatie).

De voordelen ten opzichte van de variant met meerdere portalen zijn:

• Één ingang voor gebruikers.
• De ‘presentatie’ van de organisatie is meer eenduidig.

Een aantal nadelen van meerdere portalen, zoals een andere ‘look and feel’, versnippering van het klantbeeld en grotere complexiteit van beheer, worden met deze variant niet ‘opgelost’.

Een portaal

De organisatie beschikt over één portaal waarmee de gebruiker alle dienstverlening van de organisatie op één plaats, en op een eenduidige wijze, afneemt. De functionaliteit van de achterliggende applicaties is via het portaal beschikbaar voor de gebruikers (zie figuur 3). Gegevens uit, en functionaliteit van, de achterliggende applicaties kunnen in samenhang (‘geïntegreerd’) ontsloten worden.

Het portaal beschikt over functionaliteit voor:

• Toegang: authenticatie en autorisatie.
• Interactie: Interactie met de gebruiker via formulieren.
• Proces: Functionaliteit voor het configureren en uitvoeren van processen (workflow).
• Regels: Bedrijfsregels voor het uitvoeren van processen.
• Integratie: Functionaliteit voor het uitwisselen van gegevens met de SaaS-applicaties (lezen en schrijven).

Een dergelijk portaal kan ontwikkeld worden met een ‘low code’ platform. Met een low code platform kunnen applicaties gebouwd worden zonder specialistische programmeerkennis.

De voordelen zijn:

• Gebruikers kunnen de dienstverlening van de organisatie op één plaats, en op eenduidige wijze, afnemen.
• Informatie en functionaliteit van de achterliggende applicaties kan in samenhang ontsloten worden.
• Voorbeelden: De gebruiker kan in één formulier zijn gegevens, afkomstig uit meerdere applicaties, bijwerken. Een proces (workflow) kan gebruik maken van functionaliteit uit meerdere applicaties.
• Eenduidige ‘presentatie’ van de organisatie.
• Een dergelijk portaal vereist dat de ‘achterliggende’ applicaties over een moderne architectuur beschikken:
• De logica voor gebruikersinteractie, proces, bedrijfsregels, integratie en data is gescheiden.
• Proceslogica en bedrijfsregels in de applicaties zijn configuratie waardoor de logica ‘herbruikbaar’ is door het portaal.

Deze variant is niet geschikt voor het ontsluiten van applicaties waarbij de logica niet gescheiden is, of onderdeel van de programmatuur van de applicatie is. Het ontsluiten van dergelijke applicaties leidt (‘lijdt’) tot complex, duur en tijdrovend maatwerk en de bijbehorende problematiek van beheer, onderhoud en upgrades.

Conclusie

Het ontsluiten van digitale dienstverlening is een belangrijk vraagstuk voor organisaties. Een hybride applicatielandschap met meerdere portalen kan als gevolg hebben dat gebruikers afhaken, het ontstaan van een negatief beeld over de organisatie en versnippering van waardevolle klantinformatie.

De beschreven varianten hebben hun eigen toepassingsgebied, afhankelijk van de gebruikersgroepen, de omvang van de digitale dienstverlening en de mogelijkheden van de organisatie om een geïntegreerde oplossing te realiseren. De technische architectuur van de te ontsluiten applicaties kan een belemmering voor een geïntegreerde oplossing zijn.

Organisaties moeten een bewuste keuze maken. Architectuur kan een belangrijke rol spelen bij het maken van die keuze.

Wordt vervolgd.