Yearly Archives: 2015

Onderwijscatalogus bij het IDCollege op #samboict

Lara Bok en Bram Lankreijer vertellen over hun onderwijscatalogus op de 32ste saMBO-ICT Conferentie. In de doorgroei willen ze voorgesorteerde leertrajecten aanbieden met keuzedelen, aansluitend bij de herziene kwalificatiestructuur. Vanuit hun ambitie maken ze het zichzelf niet makkelijk: Het ID College heeft in haar ambitie staan dat ze maatwerk en gepersonaliseerd onderwijs willen bieden. Dat is bij grote instellingen altijd al een uitdaging geweest, massamaatwerk enzo.

De complexiteit ontstaat doordat je op grote schaal je onderwijsaanbod, de bouwblokjes in je opleidingen, je faciliteiten en de keuzes van studenten combineert tot een werkbare planning. Waarbij de hele onderwijslogistiek nog betaalbaar blijft lijkt me. In hun applicatielandschap betekent dat koppelingen tussen EduArte, GPUntis en SharePoint. Het geheel wordt wel onder architectuur gebouwd.

De uitgangspunten die ze hanteren:

De onderwijscatalogus centraal. Het is gevuld met roosterbare onderwijsproducten, die qua omvang per stuk ongeveer 10 weken duren. Het kan ook kleiner, maar zo is het meer beheersbaar. De verwachting is dat je algemene producten kunt hergebruiken.
Haalbaarheid boven perfectie! Iets dat ik vaak tegen mezelf moet zeggen, dus had ik wel gevoel bij deze kreet. Soms kun je zo lang bezig zijn met het ideaalplaatje van processen met applicaties dat je eigenlijk nooit aan de slag kunt gaan. De valkuil is dan dat je pas gaat implementeren als alle puzzelstukjes klaar zijn. Terwijl het handiger is om te gaan werken met dat stukje dat haalbaar is.
Zoveel mogelijk aansluiten op de bestaande systemen
Denken en werken parallel als motto. Het ideaal plaatje van ‘eerst denken, dan doen’ lieten ze los. Normaal gesproken bekijk je eerst je processen, dan de use-cases daarbinnen, dan de functionele eisen en ontwerp en pas daarna ga je bouwen en testen. In plaats daarvan leverde men de basisfunctionaliteit op, waarna steeds meer complexe mogelijkheden worden toegevoegd.

Omdat ik al eerder over het ID College geblogd had was ik nieuwsgierig naar hun applicatielandschap en de integratie tussen systemen. Concreet lijkt het me moeilijk om toe te komen met Untis en maatwerk in SharePoint On Premise als je echt wilt automatiseren. Het komt over alsof je toch veel werk hebt om de gegevens aan elkaar te knopen, aangezien Untis niet uitblinkt in koppelvlakken. Daarnaast vergt de eigen bouw in SharePoint ongeveer 1 FTE voor alleen de functionaliteit op het gebied van de onderwijscatalogus. Maatwerk blijft natuurlijk een keuze, maar dan is het goed om hier rekening mee te houden.

Met je school naar de Office365 cloud: Heb ik meer bandbreedte nodig?

Zoals met alles, dat hangt er van af. Kort omschreven is het antwoord “Ja”, als je toekomstige behoefte je huidige capaciteit overschrijdt. Praktisch gezien maakt het nogal uit of bestanden over je lokale netwerk lopen, met de capaciteit van je eigen switches/bekabeling/wifi of over ‘internet’. Elke handeling, bestand openen en opslaan, zijn te vergelijken met down/uploaden. Normaal gesproken als je een bestandje download van internet en het duurt 30 seconden dan is dat meestal niet erg. Ondertussen surf je verder. Als je echter een willekeurig Word bestandje opent en het duurt zo lang, dan leidt dat tot irritatie.

Onderstaande benadering gaat er vanuit:

dat je je normale netwerkschijven bij Microsoft parkeert in de vorm van teamsites met bibliotheken. Je wilt tenslotte naar de cloud of niet soms?
dat je nog niet direct iedereen aan het digitaal vergaderen en Skypen hebt.
dat je niet je complete mediatheek upload naar de Video portal en elke les aan 1000 studenten streamt.

De laatste twee zijn ook tof, maar dan zou je onderstaande stappen wat moeten aanpassen.

Bepaal het aantal gebruikers van Office365, zowel je collega’s als studenten.
Maak gebruikersprofielen (licht, medium en zwaar gebruiker)
Schat de de gemiddelde grootte van interactie (in KB) en de frequentie (aantal interacties per uur) per profiel.
Schat het percentage gelijktijdig ingelogde gebruikers.
Maak een schatting van het percentage licht, medium en zware gebruiker binnen je organisatie.
Reken bovenstaande om naar absolute aantallen personen en hun gebruik.
Vergelijk dit met je huidige capaciteit.

Als je overigens als MBO instelling op SurfNet zit dan heb je één voordeel: Van SurfNet naar Microsoft lopen rechtstreekse dataverbindingen en dat wordt als intern verkeer gezien. De bandbreedte van je eigen instelling naar SurfNet moet dan hoger zijn dan bovenstaande inschatting.

SharePoint Sitecollecties Ontwerpen: Structuurplaat voor Kwaliteitszorg

Over het belang van ontwerp en structuur in je tenant heb ik eerder geschreven. Nu een concreet voorbeeld uit de serie voor een omgeving waar de collega’s van kwaliteitszorg samenwerken met onderwijsteams. Het blijft natuurlijk een voorbeeld ter inspiratie. De nadruk ligt nog op bestanden.

Visueel (klik voor hogere resolutie):

Wat het toont is:

Het platform SharePoint zelf.
De Sitecollectie voor alles dat met kwaliteitszorg te maken heeft. Deze bevat 3 bibliotheken, een algemene, een overlegbibliotheek voor de kwaliteitszorg medewerkers en het archief. In het archief komen bestanden uit de subsites nadat deze opgeruimd worden.
Voor elke school een subsite met ‘jaarbibliotheken’. Aangezien de processen van kwaliteitszorg cyclisch zijn. Daarnaast lopen er altijd onderzoeken binnen scholen. Deze verschillen inhoudelijk van focus en omvang. De betrokkenen uit de scholen kunnen steeds wisselen. Per onderzoek wordt er daarom een groepje geautoriseerd voor een ‘onderzoeksbibliotheek’. Om de resultaten van een onderzoek bredere bekendheid te geven is er een ‘publicatiebibliotheek’. Deze is te lezen door alle medewerkers van een school.
Als de rechten geërfd zijn, dan kunnen ‘eigenaren’ beheren (iemand binnen kwaliteitszorg die dit coördineert), ‘leden’ bewerken (het team kwaliteitszorg) en ‘bezoekers’ lezen (docenten uit een school).
Als de rechten niet geërfd zijn, dan is er meestal een aparte of beperkte groep die beheer/bewerking doet.

Welke samenwerking je op welk niveau doet, hangt af van je situatie. Of je de samenwerking ‘wegstopt’ in een mapje, bibliotheek of eigen subsite is een kwestie van aanvoelen.

Ziet het er ingewikkeld uit? Ik vind natuurlijk van niet. Elke plaat die je tekent van samenwerkingsverbanden binnen grotere organisaties kent veel elementen. Het aantal subsites en bibliotheken wordt best groot. Tegelijkertijd is het voor een individu toch overzichtelijk: hij ziet namelijk alleen datgene waar hij/zij rechten op heeft.

Mocht je deze stijl handig vinden èn willen aanpassen voor andere situaties dan is hier het originele bestand.

SharePoint Sitecollecties Ontwerpen: Structuurplaat voor een publicatiesite

Over het belang van ontwerp en structuur in je tenant heb ik eerder geschreven. Nu een concreet voorbeeld uit de serie voor een omgeving waar een team iets publiceert voor anderen, een soort intranet dus.

Visueel (klik voor hoge resolutie):

Wat het toont is:

Het platform SharePoint zelf.
De Sitecollectie voor deze publicatiesite. Deze bevat behalve een bibliotheek ook andere apps.
Als de rechten geërfd zijn, dan kunnen ‘eigenaren’ beheren, ‘leden’ bewerken en ‘bezoekers’ lezen. Wij hebben zelf een (security)groep gemaakt die alle medewerkers bevat. Deze is makkelijk toe te voegen aan de (SharePoint)groep “Bezoekers”.

Mocht je deze stijl handig vinden èn willen aanpassen voor andere situaties dan is hier het originele bestand.

SharePoint Sitecollecties Ontwerpen: Structuurplaat voor je eigen profiel

Over het belang van ontwerp en structuur in je tenant heb ik eerder geschreven. Nu een concreet voorbeeld uit de serie voor je eigen profielsite. Het deel “Over mij” in SharePoint is technisch ‘gewoon’ een sitecollectie, waar je net als bij andere sitecollecties inhoud aan kan toevoegen. Dus apps, bibliotheken, lijsten en subsites etc.

Visueel (klik voor hoge resolutie):

Wat het toont is:

Het platform SharePoint zelf.
Je eigen profielsite met de standaardbibliotheek (OneDrive). In dit ontwerp is er een extra bibliotheek toegevoegd met de naam ‘Archief’. De inhoud ervan komt niet terug in de OneDrive app. Online is alles wel te benaderen. Er zijn door jezelf nog meer bibliotheken aan te leggen op elk niveau.
Een subsite met als template ‘blog’.
Zelf ben je standaard de ‘eigenaar’ en kun je beheren. In dit ontwerp hebben collega’s leesrechten op je blogsite. Deze is rechtstreeks te benaderen zonder dat ze op het hoogste niveau je OneDrive zien.

Waarom zou je overigens meerdere bibliotheken aanleggen als je OneDrive 1 TB is?

De opslagcapaciteit voor OneDrive van 1 TB die Microsoft noemt is eigenlijk het quotum van je hele collectie. Als je niets lokaal synchroniseert, dus geen ‘OneDrive voor Bedrijven’ hebt op je laptop of bureaucomputer dan kun je alles in je OneDrive bibliotheek houden.

Als je dat wel wilt, integratie in de Verkenner is nu eenmaal makkelijk, dan loop je tegen een aantal grenzen op:

De synchronisatie werkt tot ongeveer 5000 bestanden. Ik merkte al foutmeldingen bij 4618. 😉
Je krijgt een lokale kopie van je cloudbestanden. Je harde schijf loopt dan vol tenzij die minimaal net zo groot is als je gebruikte opslag in de cloud. Dat voelt een beetje dubbel: sla je op in de cloud, heb je alles nog lokaal nodig. Maar voor grote bestanden ontkom je er niet aan. Probeer maar eens een excel-bestand van 100 MB te bewerken en op te slaan zonder synchronisatie. De prestaties lopen dan hard achteruit. Laat staan als je bijvoorbeeld video-editing wilt doen.

Mocht je deze stijl handig vinden èn willen aanpassen voor andere situaties dan is hier het originele bestand.

SharePoint Sitecollecties Ontwerpen: Structuurplaat voor een projectenorganisatie

Over het belang van ontwerp en structuur in je tenant heb ik eerder geschreven. Nu een concreet voorbeeld uit de serie voor een omgeving waar de collega’s binnen projecten samenwerken. Het bestaat uit twee delen:

Een teamsite voor elk project, voor de opslag van projectdocumenten.
Sites voor ondersteunende diensten vanuit een projectbureau.

Visueel (klik voor een hogere resolutie):

Wat het toont is:

Het platform SharePoint zelf.
De Sitecollectie voor ALLE projecten. Deze bevat een bibliotheek met sjablonen (voor het schrijven van projectplannen etc.) en een lijst van alle projecten, hun status en enkele kenmerken. Het projectbureau is eigenaar van de gehele collectie. De inhoud op dit niveau is leesbaar voor elke medewerker.
Een subsite per project waar de werkgroepen elk een bibliotheek hebben. De projectleider is eigenaar van zijn projectsite.
Een subsite voor ondersteunende diensten en sturing op projecten. In onze methodiek heten die o.a. regiegroep en toetsgroep.
Als de rechten geërfd zijn, dan kunnen ‘eigenaren’ beheren, ‘leden’ bewerken en ‘bezoekers’ lezen.
Als de rechten niet geërfd zijn, dan is er meestal een aparte of beperkte groep die beheer/bewerking doet.

Als een project inclusief nazorg klaar is, dan wordt de bijbehorende site gearchiveerd. De bestanden worden overgezet in een archief en de teamsite zelf wordt verwijdert.

Mocht je deze stijl handig vinden èn willen aanpassen voor andere situaties dan is hier het originele bestand.

SharePoint Sitecollecties Ontwerpen: Structuurplaat voor medewerkers en studenten van een school

Over het belang van ontwerp en structuur in je tenant heb ik eerder geschreven. Nu een concreet voorbeeld uit de serie voor een omgeving waar de collega’s van een school communiceren met studenten. De nadruk ligt nog op bestanden. Andere vormen van communicatie komt ik binnenkort op terug. Visueel:

Wat het toont is:

Het platform SharePoint zelf.
De Sitecollectie voor deze school. Deze bevat 2 bibliotheken, een algemene en het fotoarchief.
Een subsite waar de opleidingen elk een bibliotheek hebben.
Een subsite voor een excursie met daarin een bibliotheek met opdrachten en een algemene.
Als de rechten geërfd zijn, dan kunnen ‘eigenaren’ beheren, ‘leden’ bewerken (docenten) en ‘bezoekers’ lezen (studenten).
Als de rechten niet geërfd zijn, dan is er meestal een aparte of beperkte groep die beheer/bewerking doet.

Welke samenwerking je op welk niveau doet, hangt af van je situatie. Voor grotere scholen zijn subsites per opleiding vaak beter. Daarnaast zijn er vaak nog andere onderwerpen dan een excursie te bedenken. Of je de samenwerking ‘wegstopt’ in een mapje, bibliotheek of eigen subsite is een kwestie van aanvoelen. Zelf zijn we niet te bang om subsites te creëeren. Als het ergens een rommeltje wordt dan stoort het de andere vormen van samenwerking niet.

Mocht je deze stijl handig vinden èn willen aanpassen voor andere situaties dan is hier het originele bestand.

SharePoint Sitecollecties Ontwerpen: Structuurplaat voor medewerkers van een school

Over het belang van ontwerp en structuur in je tenant heb ik eerder geschreven. Nu een concreet voorbeeld voor een omgeving waar de collega’s van een school samenwerken. Visueel:

Wat het toont is:

Het platform SharePoint zelf.
De Sitecollectie voor deze school. Deze bevat 2 bibliotheken, een algemene en het fotoarchief.
Een subsite waar de vakgroepen elk een bibliotheek hebben.
Een subsite voor het secretariaat met daarin een bibliotheek per schooljaar.
Als de rechten geërfd zijn, dan kunnen ‘eigenaren’ beheren, ‘leden’ bewerken en ‘bezoekers’ lezen.
Als de rechten niet geërfd zijn, dan is er meestal een aparte of beperkte groep die beheer/bewerking doet.

Welke samenwerking je op welk niveau doet, hangt af van je situatie. Voor grotere scholen zijn subsites per vakgroep of opleiding vaak beter. Daarnaast zijn er vaak nog andere onderwerpen zoals het roosteren, BPV, begeleiden etc. Of je hun samenwerking ‘wegstopt’ in een mapje, bibliotheek of eigen subsite is een kwestie van aanvoelen. Zelf zijn we niet te bang om subsites te creëeren. Als het ergens een rommeltje wordt dan stoort het de andere vormen van samenwerking niet.

Mocht je deze stijl handig vinden èn willen aanpassen voor andere situaties dan is hier het originele bestand.

Met je school naar de Office365 cloud: Hoe ontwerp je sitecollecties?

Geleidelijk bemerkten we dat er nogal een gat zit tussen algemene voorlichting over SharePoint en handleidingen hoe iets werkt. De eerste bestaat vaak uit mooie sheets van van vrolijke mensen die gelukkig en productief zijn. Er kan zoveel en het is zo handig, ik krijg er altijd slappe knieën van. Het schept echter hoge verwachtingen. De tweede gebruiken we in workshops en trainingen. Korte wegwijzers die uitleggen waar je moet klikken om iets te doen.

Maar van het een naar het ander is nogal een sprong. Daarom hebben we er een trajectje tussen verzonnen: Collectieontwerp. Het bestaat grofweg uit 2 delen:

Een dialoog met de eigenaar en beheerder van een sitecollectie, eventueel aangevuld met belanghebbenden uit het team. De vragen die passeren zijn o.a.:
Welke soorten samenwerking zijn er binnen het team? Welke informatie levert dat op? Welke bestanden zijn voor iedereen te lezen? Welke subgroepen hebben behoefte aan een meer afzonderlijke teamsite binnen de collectie? Welke communicatiebehoeftes zijn er?
Een grafische weergave van de sitecollectie. Deze tekeningen verhogen de kwaliteit van de dialoog tijdens het ontwerpfase. Daarnaast helpt het de beheerder ook één en ander duidelijk te maken aan zijn team.

Het einddoel is dat de behoeften van een team leidend zijn voor de geboden oplossingen binnen SharePoint.

Grofweg bestaat de grafische weergave uit:

Blokken in blokken: de bibliotheken binnen de teamsites binnen de collectie binnen het platform.
Pijlen die toegang symboliseren.
Groepjes die rechten krijgen.
Labels die aangeven of rechten overgeërfd worden.

Hieronder een algemeen voorbeeld van zo’n tekening. Ieders voorkeur voor visuele elementen verschilt natuurlijk, maar wilde deze stijl toch delen. 😉

Met je school naar de Office365 cloud: heb je structuur nodig?

De behoefte aan structuur is vaak generiek en ontstaat vaak aan twee kanten.

Als je als beheerder iets wilt beheren of controleren dan heb je behoefte aan structuur en ordening. Als deze te star is, dan zit je eindgebruikers in de weg. Het is echter onmogelijk te automatiseren als er geen structuur te ontdekken valt.
Als je als eindgebruiker de weg makkelijk wilt vinden dan heb je behoefte aan overzicht en dus ook structuur. Je raakt anders de weg kwijt in de ‘brei’ aan informatie.

Nu denkt een beheerder van een systeem vaak aan een standaard structuur voor iedereen en een eindgebruiker aan een structuur voor zichzelf. Aan de eigenaar van Office365 (heb je die al?) de schone taak om hier tussen een evenwichtige balans te organiseren. De structuur die voor iedereen, voor een team en voor een individu als logisch ervaren wordt verschilt namelijk ….

Over het algemeen kent SharePoint de volgende hiërarchie:

Platform: Microsoft is hier de baas en brengt frequent nieuwe functionaliteiten uit.
Tenant: de omgeving van je eigen school. Hier zijn enkele organisatie-specifieke instellingen te configureren. Dat wordt meestal door een beheerder uitgevoerd.
Sitecollecties: een verzameling teamsites.
Teamsites: een verzameling van functionaliteiten voor samenwerking.
Apps: dat kunnen bijvoorbeeld bibliotheken, lijsten, aankondigingen zijn.
Items: de afzonderlijke mappen/bestanden of lijstitems.

Je kunt er voor kiezen om met sitecollecties niet zoveel te doen en iedereen, middels self-service, teamsites te laten aanmaken. Binnen dezelfde collectie. Het andere uiterste is dat je elke teamsite als beheerder aanmaakt en bevolkt met de juiste mensen.

In het eerste geval ligt de verantwoordelijkheid compleet bij de eindgebruikers. Het kan organisch snel groeien, aangezien het als heel laagdrempelig ervaren wordt. De hoeveelheid teamsites zal op zich niet storend zijn aangezien je niet snel tegen het maximum van je tenant oploopt. Als er meerdere teamsites dubbel ontstaan dan moet de organisatie dit zelf oplossen.

In het andere geval heb je veel werk als beheerder. Het aanmaken van sites en toevoegen van groepen is nogal herhalend. Het werpt ook een drempel op. De kans op ‘rommel’ waar niemand de weg in weet is wel veel kleiner.

Je snapt natuurlijk wel dat we als organisatie de middenweg hebben gekozen. Praktisch gezien doordat we sitecollecties ‘weggeven’ aan teams. Daarbij dienen zij zelf aan te geven wie de beheerder wordt van hun collectie. Deze kan voor zijn team binnen de collectie zoveel en zo snel als gewenst teamsites maken. Het aanvragen van nieuwe sitecollecties laten we formeel lopen. Het aanmaken van teamsites kan informeel ontstaan binnen de teams zelf. Wat ons betreft op basis van wandelgang-verzoekjes.

De sitecollecties hebben we aangemaakt voor:

elke organieke eenheid, voor samenwerking binnen teams van diensten en onderwijs. Hierin zitten geen studenten.
elke school, voor de communicatie tussen docenten en hun studenten.
elk groter onderwerp dat dwars door de organisatie loopt, voor samenwerking dat teams overstijgt. Voorbeelden zijn VSV, ARBO, Functioneel Beheer, etc.
projecten, voor samenwerking binnen projectteams.

Binnen de context van SharePoint leidt dat voor mij tot de volgende stelling:

Leg het beheer op een zo hoog mogelijk niveau, zo laag mogelijk weg.

Daarvoor zijn wel een aantal zaken nodig:

Hou overzicht over de collecties.
Bewaak dat informatie binnen de juiste collecties ontstaat. Doe dit op een meer signalerende, voorlichtende toon dan een blokkerende.
Leidt collectie-beheerders op en blijft ze begeleiden. Bijvoorbeeld door community-vorming. Bij ons zijn dit zo’n 4% van de gebruikers initieel.
Help ze bij collectie-ontwerp met tekeningen. Een voorbeeld vind je hieronder. Hier kom ik binnenkort op terug.