Tag Archives: Office365

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.

Office365: Niet mailen maar delen

Tijdens de voorbereidingen voor Office365 en SharePoint Teamsites ontstond het motto “Niet mailen maar delen”. Vanuit de gedachte dat het rondsturen van bestanden een ouderwetse manier van samenwerken is. Handiger is om bestanden te delen met de personen die er bij moeten kunnen. Op zich is dat nog steeds zo, maar er zijn wel een paar zaken om rekening mee te houden. Daarnaast is dit motto geen dogma.

Onderstaande tips gaan er vanuit dat bekend is wie het beheer van een sitecollectie of teamsite doet! Meestal kan deze vrij diep in de organisatie weggelegd worden.

De knop ‘Delen’
De knop ‘Delen’ hoeft niet gebruikt te worden als er al gedeeld is. Dat betekent dat je beheerder al de juiste personen lees of schrijfrechten gegeven heeft. Als je op het moment gekomen bent dat je vroeger een bestand zou mailen, onderdruk dan de neiging om op ‘delen’ te klikken.
Dit zorgt er namelijk voor dat er specifieke rechten worden ingesteld op dat ene bestandje. Als een jaar later een persoon ergens anders gaat werken binnen je organisatie dan moeten al deze rechten per stuk verwijdert worden. Beter is het om van een persoon zijn rechten op een site of bibliotheek te verwijderen. Dat is voldoende als er niet overal rechten op mapjes en bestanden zijn uitgedeeld.

”Gedeeld met mij” in OneDrive
Als mappen en bestanden handmatig gedeeld worden dan komt de verwijzing hiernaar in je OneDrive. Het bestand zelf bevindt zicht op de originele plaats. Alhoewel dit handig lijkt kent dit enkele nadelen:

Het overzicht stroomt snel over. In de praktijk wordt het na meer dan 100 bestanden onwerkbaar.
Er kan geen ordening in aangebracht worden om wel overzicht te krijgen.
Bestanden die niet meer relevant voor zijn kun je niet ‘verwijderen’. De persoon die het met je deelde, moet de rechten verwijderen. Als ontvanger ‘ontdelen’ is niet mogelijk.

In de praktijk is dit overzicht alleen handig voor een tiental actuele bestanden. Zaken die dus recent met je gedeeld zijn, aangezien die bovenaan staan.

Vragen voor als je wilt delen

Is dit een bestand waar een ‘natuurlijke plaats’ voor bestaat? Dat zou de site, bibliotheek of map zijn waarvan iedereen vindt dat het daar ‘hoort’. Voorbeelden zijn de bestanden voor een vakgroep, opleidingsteam, overleg, project of specifieke dossiers.
Als er geen bibliotheek voor is, is er dan een sitecollectie waar het hoort? Die van je eigen team, school of dienst? Vraag je beheerder of hij deze bibliotheek aanmaakt en er rechten op uitdeelt.
Betreft het reguliere samenwerking waarvoor al een site of bibliotheek is gemaakt? Gebruik dan niet de ‘delen’ knop.
Wil je mensen op de hoogte brengen van een nieuw bestand of nieuwe versie? Stuur ze een mailtje. Niet met het bestand als bijlage, maar slechts met de mededeling dat het geplaatst is. Of nog beter: laat ze een waarschuwing instellen die dat automatisch doet.
Betreft het samenwerking die ad-hoc is of die zich waarschijnlijk niet herhaald? Dan is eenmalig iets sturen via mail geen probleem.
Betreft het een regulier overleg waar de vaste leden al standaard toegang hebben, maar er eenmalig op basis van de agenda iemand aanschuift? Dan is het specifieke mapje delen met die persoon geen probleem.