Rechtstreekse koppeling voor je accountbeheer?

Veel leveranciers en system integrators bieden rechtstreekse koppelingen tussen HR-platformen en specifieke bedrijfssystemen. In veel bedrijfsprocessen maak je immers gebruik van personeelsdata om bijvoorbeeld medewerkers in te roosteren. En omgekeerd wil je data uit die bedrijfssystemen gebruiken binnen je HR-systeem voor bijvoorbeeld je urenadministratie. Met een rechtstreekse koppeling kun je zulke zaken dus eenvoudig automatiseren. Vaak heeft een medewerker daarvoor wel een account en toegangsrechten nodig op zo’n systeem en de logische vraag is of je ook deze instellingen niet via die rechtstreekse koppeling kunt uitvoeren. En heb je dan eigenlijk wel een apart IAM platform nodig? Is zo’n rechtstreekse koppeling niet voldoende?

Een voorbeeld: een HR-Zorg koppeling

Laten we een concreet voorbeeld nemen. Veel zorginstellingen gebruiken geavanceerde zorgapplicaties zoals Nedap Ons die speciaal is ontwikkeld om het werk van zorgpersoneel eenvoudiger en efficiënter te maken. De software beheert onder andere cliëntdossiers, maakt het eenvoudig de werkzaamheden in te plannen, rapportages te maken en de gewerkte uren te registreren. Vanuit je HR-systeem zijn daarvoor gegevens nodig zoals de functie van medewerkers, de gecontracteerde uren en hun deskundigheid. Omgekeerd wil je in je HR-systeem bijvoorbeeld de daadwerkelijk gewerkte uren kunnen registreren om de uren- en verlofadministratie bij te houden. Met een rechtstreekse koppeling tussen je HR-systeem en dat zorgsysteem kun je dit zoveel mogelijk automatiseren. Zo kan iedereen zich richten op het échte werk en heb je zo weinig mogelijk last van administratieve rompslomp.

Daarvoor moet wel iedere medewerker een account krijgen in dat zorgsysteem inclusief de juiste rechten. Ook dat wil je natuurlijk automatiseren en ook dat kan in principe via zo’n rechtstreekse koppeling. Hiervoor moet je een zogeheten rollenmodel – of autorisatiematrix – toevoegen. Deze add-on bepaalt aan de hand van medewerkersgegevens in het HR-systeem (zoals iemands rol, afdeling, locatie etc.) welke accounts en toegangsrechten iemand nodig heeft en maakt deze aan in het doelsysteem.

Dus ja, je kunt met zo’n rechtstreekse koppeling in principe ook het account- en rechtenbeheer van je zorgsysteem automatiseren en tijd besparen op het handmatige beheer. Belangrijk is wel je te realiseren dat dit een add-on is en specifiek is bedoeld voor deze ene koppeling. En je dus vooral moet afvragen of het wel de structurele oplossing is die je uiteindelijk nodig hebt.

Meerdere systemen? Eén integraal rollenmodel

Echt toekomstvast lijkt zo’n oplossing namelijk niet. Gebruikers die maar één systeem nodig hebben, zijn uitzonderingen. In de meeste organisaties koppel je je gebruikers ook aan de Active Directory (of een andere Identity Provider) voor je Single Sign-On, geef je ze een M365 licentie, toegang tot specifieke datashares, een eigen mailaccount en een account op het HR portal. Ook krijgen veel medewerkers toegang tot een service management systeem als TOPdesk voor de uitgifte van laptops, telefoons, toegangspasjes en andere assets. Kortom, je hebt al snel te maken met meerdere doelsystemen en als je ook die systemen automatisch wilt voorzien van accounts en toegangsrechten heb je meerdere provisioning koppelingen nodig, inclusief een bijbehorend rollenmodel.

Workflow management

En als je daarop inzoomt, zie je dat die verschillende systemen ook nog onderling afhankelijk zijn. Bijvoorbeeld als je meerdere systemen een account wilt geven met hetzelfde e-mailadres en Single Sign-On wilt bieden. In dat geval wil je een gebruiker eerst registreren op je Identity Provider (Entra ID bijvoorbeeld) en daarna pas wil je de accounts aanmaken in andere doelsystemen. En dat is maar een van de voorbeelden van een workflow die je wilt toevoegen. Veel organisaties geven een nieuwe medewerker al enkele dagen vóór hun onboarding een office account, maar verstrekken pas de volledige rechten op de definitieve contractdatum. Ook kun je een extra stap inbouwen waarbij de medewerker eerst ook online de gebruikersvoorwaarden moet bevestigen.

Meerdere bronsystemen

Bovendien voldoet één bronsysteem lang niet altijd. Voor partner- en klantenaccounts in een B2B omgeving is het CRM-systeem natuurlijk een veel logischer bron, die registreer je niet in het HR-platform. En in het onderwijs zijn meerdere bronsystemen bijna standaard; het personeel wordt geregistreerd in het HR-systeem maar de studentenadministratie wordt gebruikt als bron voor je studentaccounts. En om nog even terug te komen op ons eerdere voorbeeld in de zorg, vaak worden de inhuurkrachten in een apart bronsysteem beheerd. Je wilt dan niet vanuit twee bronsystemen een vergelijkbare provisioning koppeling maken naar je zorgsysteem.

Om een lang verhaal kort te maken, als je in de vorm van maatwerk meerdere bron- en doelsystemen wilt aansluiten, een integraal rollenmodel wilt inbouwen en workflows ondersteunen ben je feitelijk begonnen een eigen maatwerk IAM platform te ontwikkelen. Je moet jezelf afvragen of dat het juiste pad is..

Robuustheid, traceerbaar en compliant

Hiervoor beschreven we wat je zoal moet regelen om accounts en autorisaties te automatiseren en ook door te groeien van één rechtstreekse koppeling naar het beheer van meerdere systemen. De nadruk lag daarbij nog op de primaire functionaliteit: hoe automatiseer je de uitgifte en het beheer van alle rechten.

Wat dan nog mist is het feit dat dat rechtenbeheer een centrale rol speelt in je IT dienstverlening en er daarom ook nog allerlei aanvullende eisen zijn. Uiteraard moeten de koppelingen zeer goed worden beveiligd om te voorkomen dat iemand vanaf één plek al je autorisaties kan manipuleren. Ook wil je bijvoorbeeld extra controles inbouwen bij bulkwijzigingen om te voorkomen dat iemand per ongeluk de hele organisatie offline haalt. Alle handelingen moeten achteraf traceerbaar zijn en het platform moet audit trails ondersteunen. Je moet op ieder moment kunnen aantonen dat je voldoet aan alle wet- en regelgeving, én uiteraard aan het eigen organisatiebeleid. Ook wil je regelmatig alle rechten controleren op eventuele mismatches, je rollenmodel eenvoudig kunnen aanpassen aan organisatiewijzigingen en voortdurend dat rollenmodel steeds verder optimaliseren. Bij een modern IAM platform als HelloID hebben we daarom geïnvesteerd in een aparte Governance module om deze optimalisatie en compliancy zo goed mogelijk te ondersteunen.

Conclusie

Zo’n rechtstreekse koppeling tussen een bronsysteem en een doelsysteem is dus een prachtige oplossing om operationele gegevens uit te wisselen voor specifieke organisatieprocessen. Zoals in het voorbeeld van AFAS en Nedap Ons waarin je personeelsinformatie, roosters, verlofgegevens en gewerkte uren uitwisselt om je zorgprocessen te vereenvoudigen. Dan klinkt het logisch dat je diezelfde koppeling ook gaat gebruiken voor je accountbeheer op dat zorgsysteem; je bent dan direct verlost van je dagelijkse handmatige mutaties.

Toch is het zelden of nooit rendabel om die rechtstreekse koppelingen daarvoor ook structureel te blijven gebruiken. Je identiteits- en rechtenbeheer is een kritisch bedrijfsproces waarvan de scope veel groter is en waarin veel meer systemen moeten samenwerken. Bovendien moet je voortdurend kunnen aantonen dat je er volledig grip op hebt. Dat lukt niet met een verzameling van individuele koppelingen en juist daarom investeren organisaties in IAM-systemen. Je ziet daarbij dat al bij organisaties van enige tientallen medewerkers en een paar doelapplicaties de tijdwinst die je behaalt veel groter is dan met zulke individuele koppelingen. We maken die businesscase graag met je!