In deze blogpost schets ik een belangrijke situatie die je tijdens formeel digitaal vergaderen met 360° tegen kan komen en onze oplossing. Hier komt het op neer:

“Waarom handmatig doen als het automatisch kan”

360° is als basis een DMS, en in een DMS bewaar je belangrijke bedrijfsinformatie, waaronder ook voorstellen. Met de optionele module voor digitaal vergaderen ondersteunt 360° het formele vergaderproces waar tijdens een bestuursvergadering wordt gediscussieerd, gestemd en besloten over voorstellen en andere stukken die op de agenda van de vergadering zijn gezet. En de deelnemers aan de vergadering hebben toegang nodig tot de stukken.

De situaties:

In het huidige product worden twee situaties ondersteunt met 360°, open of afgeschermd. In de eerste situatie zijn alle documenten in het DMS voor alle gebruikers toegankelijk en heeft iedereen minimaal leesrechten. Van het personeelsdossier van de financieel directeur tot een gearchiveerde email over de invulling van de kerstborrel, alle werknemers met toegang tot het DMS kunnen bij deze informatie. In deze situatie kunnen deelnemers aan een bestuursvergadering vanzelfsprekend altijd bij de stukken op de agenda en kan er over gediscussieerd, gestemd en besloten worden. Geen probleem dus, plaats de stukken op de agenda en lekker transparant vergaderen.

In de tweede situatie gaan we uit van afscherming van gevoelige informatie. Het personeelsdossier van de financieel directeur is uitsluitend toegankelijk voor HR en een select gezelschap, en de email over de kerstborrel is alleen inzichtelijk voor het team van de organisator van het evenement.
Als beide zaken op de agenda van de eerstvolgende bestuursvergadering staan dan zal iemand de deelnemers moeten helpen om bij de twee documenten te komen. Uiteraard kunnen we in dit moderne tijdperk alles uitprinten of rondmailen, maar als we daar geen voorstander van zijn en we de informatie eenvoudig vanuit onze digitale vergadering op de iPad willen raadplegen zal vooraf de verantwoordelijke die toegang heeft de nodige machtigingen moeten uitdelen en wellicht deels achteraf weer intrekken.
En al snel zal blijken dat het handmatig uitdelen en weer intrekken van al deze machtigingen op alle vergaderdocumenten veel tijd kost en foutgevoelig is.

De oplossing:

Juist voor deze situatie hebben we een extra token ontwikkeld die we op kunnen nemen in de rechtenmatrix van alle of een selectie documenten in het DMS. Als u zich afvraagt wat een token is dan kunt u onderaan de blogpost een uitleg met voorbeeld vinden. In het kort is een token een groep met dynamisch lidmaatschap.

Als we teruggaan naar de vergadering, dan is het token wat we nodig hebben voor vergaderdocumenten zeer welkom. We willen dat deelnemers aan een vergadering toegang krijgen tot alle documenten die tijdens de vergadering behandeld worden. Documenten kunnen in meer vergaderingen tegelijk behandeld worden en deelnemers kunnen lid zijn van verschillende besturen. Incidentele deelnemers of plaatsvervangers kunnen last-minute uitgenodigd worden om aan te schuiven. En als een document niet meer op de agenda van een vergadering staat moet de toegang daar ook direct op worden aangepast. Handmatig rechten beheren en deze aanpassingen doorvoeren is foutgevoelig en kost veel tijd. Zie daar de behoefte en tevens de functionaliteit die het token realiseert.

In de volgende post gaan we in op mogelijke variaties op het universele token voor deelnemers aan vergaderingen, het ‘meeting members’-token.

Wordt vervolgd

Wat is een token?

Een token kun je zien als een groep met hierin 0, 1 of meer personen als lid. De leden van deze groep kunnen op elke moment verschillen afhankelijk van de omstandigheden, status of eigenschappen van het document of een gerelateerd object. Bij het bepalen van machtigingen op een object zoals een document bepaal je ten eerste ‘wie’ er rechten krijgt en ten tweede ‘welke’ rechten er worden uitgedeeld. Het token geeft antwoord op de ‘wie’-vraag. Een voorbeeld van een eenvoudig token is het [CREATOR] token. Bij het creëren van een document krijgt de persoon die het aanmaakt (de ‘creator’) speciale rechten op het document. Welke rechten dat zijn bepalen we ergens anders maar we willen voor elk uniek document dat de maker altijd rechten krijgt. Een voordeel van een token boven een standaard rechtengroep is dat je direct inzichtelijk hebt wie er rechten krijgen op een object, want de leden worden bij naam getoond i.p.v. de groepsnaam, en dat je per object een op het object afgestemde lijst met groepsleden hebt.