Milloin SharePoint-lista muuttuu sovellukseksi?

SharePoint on luonteeltaan itsepalveluympäristö johon loppukäyttäjät voivat rakentaa monenlaisia omaa sekä organisaation toimintaa tehostavia ja tukevia ratkaisuja.

Tämä voi kuitenkin johtaa ikäviin tilanteisiin. SharePoint -ympäristö on pahimmillaan sekä asiakkaan että toimittajan painajainen. Asiakkaan on vaikeaa ymmärtää miksei hän saa välittömästi tukea SharePointissa olevaan elintärkeään sovellukseen X. Samaan aikaan toimittaja ihmettelee mikä tämä sovellus X on ja kuka sen on rakentanut.

Mikäli SharePoint ei ole tuttu tuntuu koko keskustelu aivan absurdilta.

Mikä SharePointin hallinnassa sitten on vaikeaa? Yksi merkittävä tekijä on ettei käyttäjät miellä tekemiään ratkaisuja ratkaisuiksi ollenkaan. Paikalla ei ole käynyt konsulttia tai koodaajaa. Ihan itse tein nopeasti. Pikku juttu.

Näin syntyneitä ratkaisuja ei saateta virallisen tuen ja hallintamallin alaisuuteen. Eihän ne nyt oikeasti ole mitään ratkaisuja. Nopeasti kyhättyjä juttuja vain. Käteviä, hyödyllisiä ja tärkeitä kylläkin.

Esimerkki – Sopimusdokumentit

Tutustutaan ongelmaan esimerkin avulla. Yrityksen sopimuksista vastaava henkilö haluaa perinteisen levyjaon tilalle jotain kehittyneempää ja siirtää kaikki sopimukset SharePointiin. Aluksi hän luo sopimuksia varten dokumenttikirjaston. Ajansaatossa toimintamalli täsmentyy ja dokumenttikirjastoon lisätään pieniä lisäominaisuuksia.

Missä kohtaa SharePoint-lista muuttuu ratkaisuksi joka olisi syytä siirtää IT:n haltuun?

1) Lähtötilanne – Dokumenttikirjasto

Aluksi sopimusvarasto on pelkkä SharePointin dokumenttikirjasto, johon sopimukset tallennetaan.

Sopimuksista vastavaa henkilö on tyytyväinen kun dokumenttikirjaston pääsyoikeuksia voi hallita helposti ja sopimukset löytyvät haulla.

2) Sopimusten metatietojen lisääminen

Vanhassa mallissa sopimukset tallennettiin asiakaskohtaisiin kansioihin. Olisi näppärää mikäli sopimuksia voisi edelleen käsitellä ”nippuina” asiakkaittain. Miksei samalla koota kaikkia sopimuksen perustietoja metatiedoiksi, jolloin niitä voi hyödyntää esimerkiksi näkymien rakentamisessa.

Lisätään sopimukselle seuraavat metatiedot.

• Yritys jonka kanssa sopimus on tehty
• Sopimuksen viimeinen voimassaolopäivä
• Sopimuksen tekopäivä
• Sopimuksen tekijä
• Sopimuksen arvo

Nyt sopimukset voi niputtaa asiakkaittain.

3) ”Minun sopimukseni” -näkymä

Sopimusmäärän kasvaessa tulee tarve lisätä dokumenttikirjastoon erilaisia näkymiä. Tehdään ”Minun sopimukseni” -näkymä, jossa näkyy ainoastaan sopimukset joihin minut on merkitty vastuuhenkilöksi.

Tämä saadaan aikaan suodattamalla (filter) listan rivejä vastuuhenkilön perusteella.

Valmis näkymä näyttää tältä.

4) Lisää älyä laskettavaien sarakkeiden avulla

Eräänä päivänä tärkeä sopimus jää uusimatta koska kukaan ei huomannut sen menevän vanhaksi. Näppäräsorminen kaveri lisää sopimusarkistoon laskettavan sarakkeen (calculated column), joka näyttää montako päivää sopimus on vielä voimassa.

Samalla päivitetään näkymät näyttämään ainoastaan voimassaolevat sopimukset.

Sopimusarkisto näyttää nyt tältä.

5) Lisää väriä sarakkeiden muotoilulla

Vanhenevat sopimukset pitää kuitenkin erottua selvästi muista sopimuksista. Käytetään sarakkeen ehdollista muotoilua (conditional formatting) ja maalataan punaisella kaikki sopimukset joiden loppumispäivä on seuraavan 30 päivän sisällä.

6) Oikealle henkilölle tieto sopimuksen päättymisestä

Havaitaan ettei pelkkä punainen väri listalla riitä. Rakennetaan Flow:n avulla työnkulku joka tarkistaa kerran päivässä seuraavan 30 päivän aikana vanhenevat sopimukset ja lähettää sopimuksen vastuuhenkilölle sähköpostia vanhenemisesta.

7) Sopimustyyppien omistajat

Sopimusmäärän paisuessa organisaatiossa nimetään eri sopimustyypeille omistajat.

Sopimuslistan vastuuhenkilö (responsible) on sopimuksen tekijä. Sopimustyypin omistaja (owner) taas vastaa sopimussalkusta.

Tehdään SharePoint lista, johon tallennetaan tieto sopimustyypeistä sekä niiden omistajista. Tarvittaessa sopimustyypillä voi olla useampi omistaja.

Lisätään uusi sopimustyyppi Lookup-kenttänä sopimuskirjastoon.

Nyt sopimuksille voidaan valita sopimustyyppi, jonka takaa löytyy kyseisen sopimussalkun omistaja.

Muutetaan vanhenevista sopimuksista muistuttavaa työnkulkua siten että muistutus lähtee kyseisen sopimustyypin omistajalle.

8) Rivitasoinen pääsynhallinta

Sopimuskirjaston pääsynhallinta on suoraviivaista. Kaikki joilla on pääsy sopimuskirjastoon voivat nähdä ja muokata kaikkia sopimuksia.

Jossain kohtaa ratkaisun elinkaarta pääsynhallintaa halutaan rajoittaa. Kaikki sopimuskirjastoon pääsevät voivat lisätä uusia sopimuksia, mutta he näkevät ainoastaan itse lisäämänsä sopimukset.

Tämä on helppo toteuttaa kirjaston rivitason oikeuksilla (Item-level Permissions).

Ratkaisun pohjana oleva dokumenttikirjasto ei kuitenkaan tue tätä. Ensin pitää luoda sopimuksia varten lista (list) ja siirtää kaikki sopimukset sinne.

Listassa sopimusdokumentit ovat rivin liitteinä, joten käyttökokemus hieman muuttuu. Se on rivitason oikeuksien suoraviivaisen toteutuksen hinta.

9) Hienojakoisempi pääsynhallinta

Myöhemmin halutaan rajoittaa myös sopimussalkkujen omistajien pääsyoikeuksia siten etteivät he näe kuin oman salkkunsa sopimuksia. Sopimuksen lisääjä voi toki jakaa (share) kyseisen rivin manuaalisesti oikealle henkilölle. Mutta kuka oikeasti muistaa?

Miten tämä voidaan automatisoida?

Tehdään Azure-palveluun Functions, joka saa paremetrina sopimuskirjaston rivin id:n sekä henkilön sähköpostiosoitteen. Koodin avulla henkilölle annetaan Contributor-oikeudet kyseiseen sopimusarkiston riviin.

Funktio on PowerShell:iä jossa käytetään PnP-kirjaston Set-PnPListItemPermission -komentoa. Huomaa ettei PnP-komentoja voi ajaa Functions:ssa ennen tarvittavien dll-tiedostojen lisäämistä.

Lopuksi tehdään Azureen Logic Apps, joka käynistyy kun sopimuskirjastoon luodaan uusi rivi. Logic Apps hakee valitun sopimustyypin omistajan tiedot ja antaa omistajalle uuteen sopimusriviin contributor-oikeudet (kutsumalla äsken luotua Functions-koodia).

Yhteenveto

Esittämäni sopimuskirjasto-esimerkki kuvaa miten murheelliset SharePoint-ratkaisut usein syntyvät. Jollain on ongelma jonka voi SharePointilla nopeasti ratkaista. Ajan myötä ratkaisua viilataan ja siihen lisätään kaikkea pientä.

Muutaman vuoden kuluttua kukaan ei muista ratkaisun tekijää. Saati mitä pieniä viilauksia se sisältää.

Palataan vielä alkuperäiseen kysymykseen.

Missä kohtaa SharePoint lista-muuttui ratkaisuksi joka olisi syytä siirtää IT:n haltuun?

Tämä on tietenkin kompakysymys sillä juuri tämä ajattelumalli johtaa ongelmiin. Ratkaisun siirtoa virallisen hallintamallin alaisuuteen ei punnita ratkaisun teknisen monimutkaisuuden perusteella. Siihen pitäisi vaikuttaa ainoastaan ratkaisun merkitys liiketoiminnalle.

Sopimuskirjaston osalta siirto olisi pitänyt tehdä kun ensimmäinen dokumenttikirjasto sopimuksia varten luotiin.