Sivustot vai ryhmät, osa 2/2 – hallinta, oikeudet ja navigointi

O365-palvelu tarjoaa kaksi keskenään kilpailevaa ryhmätyöalustaa – SharePoint-sivustot ja O365 Ryhmät. Kumpi kannattaa valita ja miksi? Tässä artikkelissa pohditaan päätöstä työryhmätilojen perustamisen, hallinnan, käyttöoikeuksien ja usean ryhmän kanssa toimimisen näkökulmista. Juttusarjan ekassa osassa valintaa perusteltiin ryhmätyöominaisuuksien kantilta.


Työryhmätilan perustaminen

Uuden ryhmän luonti
Uuden ryhmän luonti

Ryhmän luonti onnistuu joka pulliaiselta. Houkutteleva plussanappi on aina hyvin saatavilla ryhmälistauksen vieressä, ja jos oikeuksia ei ole erikseen pääkäyttäjän toimesta poistettu, luontiin ei vaadita lupaa. Ryhmän luontilomakkeella on pakko koskea vain yhteen kenttään eli määrittää ryhmälle nimi. Halutessaan voi lisäksi kirjailla kuvaustekstin ja muuttaa oletusvalintoja ryhmän kielestä, julkisuudesta ja ilmoitusasetuksista. Seuraavalla sivulla voi halutessaan lisätä ryhmään jäseniksi muita käyttäjiä, ja sitten ryhmä onkin käyttövalmis.

SharePoint-sivuston luonti itsepalveluna
SharePoint-sivuston luonti itsepalveluna

SharePoint-sivuston luomisessa käytetään organisaation valinnan mukaisesti jompaa kumpaa tapaa:

  1. työryhmäsivusto perustetaan luomalla Sivuston sisältö -sivun kautta uusi alisivusto tai
  2. käyttämällä itsepalveluna uuden työryhmäsivuston luontilinkkiä.

Kummallakin tavalla toimittaessa käyttäjille pitää ensin määrittää oikeus lisätä uusia alisivustoja sivustokokoelmaan. Tätä ei kuitenkaan kannata säikähtää, koska alisivuston luonnille voidaan määrittää oma oikeustaso, joka ei sisällä muita oikeuksia.

Ykköstapa sivuston luontiin on hieman monimutkaisempi, mutta se mahdollistaa mukautetun työryhmätemplaatin valinnan. Kakkostapa on yhtä yksinkertainen kuin ryhmän luonti (syötä vain nimi), mutta syntyvä sivusto on aina SharePointin perustyöryhmäsivusto ilman templaatin tarjoamia mukautuksia.


Käyttäjänhallinta ja käyttöoikeudet

Ryhmillä on käytännössä kaksi oikeustasoa: omistajat ja jäsenet. Ryhmän perustaja on aina automaattisesti omistaja, ja hän voi nostaa muita jäseniä omistajiksi. Kaikilla omistajilla on keskenään samantasoiset oikeudet hyväksyä uusia jäseniä ryhmään, määrittää uusia omistajia ja muokata ryhmän asetuksia. Sisältöjen näkökulmasta sekä omistajilla että jäsenillä on ihan samanlaiset oikeudet – kaikki saavat luoda, muokata ja poistaa mitä tahansa sisältöjä. Ryhmään ei voi määrittää poikkeavia oikeustasoja tai pelkkiä lukuoikeuksia.

Ryhmä voi olla julkinen tai yksityinen. Valinta tehdään ryhmän perustamisvaiheessa, ja sitä ei voi myöhemmin muuttaa. Valinnasta huolimatta ryhmän nimi, kuvaus ja jäsenet näkyvät aina kaikille, mutta vain julkisen ryhmän sisältöjä pääsee tarkastelemaan liittymättä ryhmän jäseneksi. Yksityiseen ryhmään pääsee jäseneksi vain, jos ryhmän omistaja hyväksyy liittymispyynnön.

Ryhmän käyttäjänhallinnassa tarjolla ovat houkuttelevasti myös AD-oikeusryhmät ja muut työryhmät, mutta valitettavasti ryhmään lisätä voi vain yksittäisiä käyttäjätunnuksia. Aika työlästä, jos tarjolla jo olisi valmiit AD-oikeusryhmät esimerkiksi organisaation yksiköille ja tiimeille. Mikäli käytössä on Azure AD:n premium-versio, pääkäyttäjä voi kuitenkin muodostaa käyttäjäattribuuttien perusteella dynaamisia ryhmiä tätä ongelmaa taklaamaan. Dynaamiseen ryhmään ei ole mahdollista lisätä käyttäjiä manuaalisesti.

SharePoint-sivustolla oikeustasoja on oletusarvoisesti kolme: omistajat, jäsenet ja lukijat. Kuten ryhmissä, sivuston perustaja saa omistajaoikeuden ja voi lisätä muut käyttäjät valitsemalleen oikeustasolle. Omistaja voi käyttöoikeuksien lisäksi muokata sivuston asetuksia ja rakennetta esimerkiksi lisäämällä uusia listoja tai kirjastoja. Jäsenillä on ryhmien tavoin luonti-, muokkaus- ja poisto-oikeus kaikkeen sivuston sisältöön, mutta lukijat pääsevät vain tarkastelemaan ja lataamaan sisältöjä.

Ryhmistä poiketen sivustolla on mahdollista käyttää AD:n oikeusryhmiä, ja hyvä käytäntö onkin pudottaa AD-ryhmä sivuston ja roolin määrittävään SharePoint-oikeusryhmään (esimerkiksi tiimin jäsenet sisältävä ryhmä tiimityösivuston Jäsenet-oikeusryhmään). Usein työryhmien jäsenyydet eivät kuitenkaan noudata muita järjestelmiä varten luotuja oikeusryhmiä, ja tällöin sivustoilla käytetään yksittäisten käyttäjien lisäämistä kuten ryhmissäkin.

Vakio-oikeustasojen lisäksi sivustolla on mahdollista luoda omia käyttöoikeustasoja. Yleisin toive on mahdollistaa kaikille työryhmän jäsenille sisällön luonti ja muokkaus, mutta estää poistaminen. Oikeuksien hallinta on siis selvästi monipuolisempaa, mutta myös huomattavan paljon monimutkaisempaa SharePointissa. Sivuston oikeuksien jakaminen on vähän liiankin helppoa ja virheiden riski suuri.

Ulkoiset käyttäjät

Organisaation ulkoisia käyttäjiä voi tällä hetkellä lisätä vain SharePoint-sivustoihin, mutta ulkoisten käyttäjien pääsy myös ryhmiin on työn alla ja tulossa varmasti käyttöön jo kesän kieppeillä. Ulkoisen käyttäjän voi oikeuttaa koko sivustoon kirjautumisen kautta esimerkiksi jäsen- tai lukijarooliin. Yksittäisiä tiedostoja työryhmästä voidaan jakaa linkin kautta joko kirjautumista vaatien tai (tarvittaessa määräaikaisella) anonyymilinkillä.


Hallinta

Pääkäyttäjän näkökulmasta ryhmät tuntuvat helposti villin lännen ratkaisulta. Fiilis johtunee osittain siitä, että Microsoft on hiukan hitaasti tuonut työkaluja ryhmien hallintaan – esimerkiksi uuden ryhmän luonti oli kaikilla käyttäjillä automaattisesti sallittuna pitkään ilman rajoittamismahdollisuutta. Tällä hetkellä ryhmien luonnin voi estää määrätyiltä käyttäjiltä, ja ryhmien yksilöivään tunnisteesen voi liittää automaattisen vakio- tai käyttäjän attribuuttiin perustuvan tekstin. Tällä pyritään estämään esimerkiksi johtoryhma@organisaatio.fi -tyyppisten varattujen nimien käyttö. SharePointin sivuston luonti on perinteisesti tapahtunut vain harvojen ja valittujen (ts. IT-osaston) toimesta, jolloin syntyviä sivustoja on ollut helppo kontrolloida. Itsepalvelumallia (kts. osa 1) käytettäessä sivustonkin luominen on yksinkertaista.

poista ryhma
Ryhmän poiston vahvistusviesti

Sekä ryhmien että sivustojen tietojen listaaminen ja käsittely onnistuu helpoiten PowerShell-komennoilla. Pääkäyttäjän käyttöliittymässä ryhmät löytyvät Exchangen hallintanäkymästä ja työryhmäsivustot SharePointin Sisältö ja rakenne -näkymästä. Ryhmät ovat teknisesti sivustokokoelman veroisia ja jos vain levytilaa riittää, kappalerajoitus ei ihan heti tule vastaan (500t per tenantti). Työryhmäsivustoja suositellaan luotavan yhteen sivustokokoelmaan korkeintaan 2000 kpl, mutta rajoitus kiertyy helposti hajauttamalla sivustot esimerkiksi tyypin mukaan eri sivustokokoelmien alle.

Jos käyttäjä poistaa vahingossa ryhmän, se poistuu lopullisesti. Sisältöineen. Ei mahdollisuutta palauttaa pääkäyttäjänkään toimesta. Hui! Poistettu sivusto putkahtaa roskakoriin, josta se on helposti palautettavissa käyttöön. Ryhmillä ei ole keskinäistä hierarkiaa tai rakennetta. Sivustot sijaitsevat aina jonkin sivustokokoelman alla, ja niitä voi tarvittaessa siirrellä paikasta toiseen PowerShell-komennoilla (saman sivustokokoelman sisällä siirto onnistuu ihan käyttöliittymänkin kautta).

itsepalvelusivuston luonti
Sivuston luonti itsepalveluna – valitse käytäntö

Entä sitten, jos sivustoja tai ryhmiä halutaan poistaa tai arkistoida? Ryhmiin ei ole tällä hetkellä kytkettävissä mitään elinkaaren hallinnan ominaisuuksia. Sivustojen puolella vaihtoehtoja on paljon, mutta käyttöönotto vaatii määrittelyä ja konfigurointityötä. Itsepalveluna luotavaan sivustoon voidaan liittää pakollisena valinta sivustoon liittyvästä käytännöstä. Käytäntö huolehtii esimerkiksi sivuston siirtämisestä vain lukutilaan tai poistamisesta tietyn kalenteriajan kuluttua.

 


Navigointi ja tiedon löytyminen

Harvalla käyttäjällä on onni työskennellä vain yhdessä työryhmässä. Yhä useammin myös suositaan avoimuutta ja työryhmät perustetaan siten, että kaikilla organisaation jäsenillä on vähintään lukuoikeus sisältöihin. Tällöin tieto ei siiloudu vaan työn tulokset kertyvät yhteiseksi tietopääomaksi. Vai turhaksi tietotulvaksi? Ja mistä ne tärkeät asiat sitten löytyvät? Kymmenien tai satojen sivustojen kanssa navigointi ja tiedon löytäminen ansaitsevat erityishuomiota.

Siirtyminen työryhmästä toiseen

Ryhmien navigaatio muodostuu automaattisesti. Aktiiviset ryhmät löytyvät sähköpostin ja OneDriven vasemmasta navigointipalkista, ja kaikkien ryhmien selailu onnistuu vohvelivalikon Henkilöt-valinnan takaa. Ryhmän voi merkitä suosikiksi, jolloin sen saa pysymään navilistauksen yläreunassa vaikka muut ryhmät hurauttaisivat aktiivisuudessa ohi. Tarkkaa järjestystä ei kuitenkaan voi kiinnittää, vaan suosikit listautuvat lisäysjärjestyksessä.

Ryhmille ei ole omaa kuvaketta vohvelivalikossa, mutta ryhmät integroituvat erittäin hyvin muihin O365-palveluihin. Ryhmiin pääsee siirtymään sähköpostin, OneDriven, Plannerin ja Henkilöt-valikon kautta. Ryhmän tiedostoja tai kalenteria käytettäessä muiden ryhmien navigointilistaus säilyy näkösällä vasemmassa reunassa.

Esimerkki työtilahakemistosta
Esimerkki työtilahakemistosta

Sivustosta toiseen navigointi tapahtuu saman sivustokokoelman sisällä yleensä jaetun päänavigaation kautta. Tällöin sivuston oma sisäinen navigaatio (listat ja kirjastot) löytyy sivun vasemmasta reunasta. Kun sivustoja on paljon, loppuu päänavigaatiosta kuitenkin nopeasti tila – ja jos työryhmiä on hajautettu eri sivustokokoelmiin, ei näiden välillä navigointiin ole tarjolla mitään valmista komponenttia. Tällöin sivustoille rakennetaankin lähes poikkeuksetta yhteinen koontisivu tai työtilahakemisto, jossa työryhmäsivustojen listausta voi rajata sivustolta kerättyjen metatietojen tai hakusanan perusteella.

viimeisimmat
Viimeksi päivittyneet sivustot

Sivustoihin siirtyminen muista O365-palveluista tapahtuu vohvelivalikon Sivustot-kuvakkeen takaa. Sivuston voi merkitä seurattavaksi, jolloin se listautuu Sivustot-sivulle. Sivulle nousee myös automaattisesti tarjolle sellaisia sivustoja, joiden arvellaan kiinnostavan sinua – sekä uutena myös sivustoja, joiden sisällöissä on tapahtunut muutoksia.

Haku

Ryhmien hakutoiminnoissa on selkeästi vielä parantamisen varaa. Yksittäisen ryhmän sisällä haun voi suorittaa ainakin keskustelu- ja tiedostonäkymässä. Haku kohdistuu vain siihen sisältöön, jossa ollaan – eli koko ryhmän tiedostoista, keskusteluista ja muistiinpanoista ei pysty yhtä aikaa hakemaan. Ryhmärajat ylittävä haku on myös heikossa jamassa, sillä tällä hetkellä SharePointin hakukeskuksesta pystyy hakemaan vain julkisten ryhmien tiedostoja.

Sivustojen puolella haku jyrää. Haun voi kohdistaa kyseiseen sivustoon tai ihan kaikkialle, käyttöoikeuksien rajoissa toki. Haku palauttaa kaikenlaisia kohteita eli tiedostojen lisäksi keskustelut, tapahtumat ja tehtävät löytyvät haulla. Mikäli sivustoilta tai tiedostostoilta on kerätty mukautettuja metatietoja, niitä voidaan käyttää haun rajaamiseen. Hyvät hakutoiminnot saattavat kallistaa vaa’an sivustojen puolelle ainakin isossa ja avoimesti toimivassa organisaatiossa.


Yhteenveto

Jos valinta sivustojen ja ryhmien välillä ei ole työryhmätilan ominaisuuksista kiinni, katseet suunnataan yleensä siihen, miten hyvin alustat istuvat jo olemassa oleviin palveluihin ja prosesseihin. Dokumenttien hallinnan ja tiedon löytymisen vaatimukset saattavat puoltaa sivustojen käyttöä. Tuttu nyrkkisääntö sanoo, että ME = ryhmä, ME + PROSESSI = sivusto – ja oikeassa on, ainakin jos prosessilla tarkoitetaan työryhmiin tai niiden tuottamiin sisältöihin liittyviä automatisoituja käytäntöjä ja työnkulkuja. Jos kuitenkin työryhmien työstämiä dokumentteja on hallittu määrä (=siirrettävissä työn päätyttyä prosessin piiriin) tai niiden hyödyntäminen jatkossa ryhmätyön päätyttyä ei ole olennaista, ryhmät tarjoavat ketterän työalustan.

Toinen päätökseen vaikuttava näkökulma on käyttökokemuksen integroituminen muuhun työhön. Ryhmillä ja sivustoilla on merkittävä periaatteellinen ero – ryhmää voisi kuvailla sovelluskokoelmaksi siinä missä SharePoint-sivusto on webbisivu. Tällä hetkellä myös Microsoft-maailma rullaa kohti erikoistuneista erillisistä palasista koostuvaa sovellusajattelua, mutta monessa organisaatiossa ollaan vielä syvällä perinteisemmän intranet-sivuston ja sähköisten työpöytien maailmassa, jossa työskentelyn suotaisiin tapahtuvan yhden (SharePoint-)kontekstin sisällä.

Mitä mieltä sinä olet? Mihin ratkaisuun teillä on päädytty ja miksi?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s