Mitkä intranet-alustat eivät vaadi IT-resursseja käyttöönottoon?

Useimmat intranet-toimittajat väittävät, että heidän alustansa on helppo ottaa käyttöön. Harvempi kertoo, mistä tuo ”helppous” oikeastaan riippuu – yleensä kyse on pienemmästä teknisestä vaatimustasosta kuin mitä alusta alun perin antaa ymmärtää. Monet asennusprosessit, jotka näyttävät yksinkertaisilta myyntiesittelyssä, vaativatkin sopimuksen allekirjoittamisen jälkeen todellista IT-osaston osallistumista: kertakirjautumisen määrittäminen, käyttöoikeusrakenteen rakentaminen, hakemistopalvelun kytkeminen sekä ongelmien ratkaiseminen, kun järjestelmä lakkaa toimimasta ensimmäisten käyttöviikkojen aikana. Yritykselle, jolla ei ole erillistä IT-osastoa hoitamaan tätä työtä, ”helppo asennus” ja ”todellinen asennus” voivat lopulta osoittautua kahdeksi hyvin erilaiseksi kokemukseksi.

Rehellinen tapa arvioida tätä ei ole kysyä, onko alusta helppokäyttöinen, kun se on kerran otettu käyttöön. Sen sijaan on kysyttävä nimenomaan, mitä teknisiä toimenpiteitä on tehtävä ennen kuin alusta voi ylipäätään toimia, ja kenen odotetaan hoitavan ne.

Mistä IT-riippuvuus todellisuudessa johtuu asennuksen aikana

Asennusvaiheen IT-riippuvuus johtuu yleensä kolmesta lähteestä, ja ne on syytä mainita suoraan, koska ne tulevat esiin lähes jokaisessa alustavertailussa, vaikka markkinointikielessä ne yritetäänkin sivuuttaa.

Ensimmäinen on tunnistautuminen ja pääsy. Jokaisen intranetin on tiedettävä, keitä sen käyttäjät ovat ja mitä he saavat nähdä, ja alustat hoitavat tämän kahdella tavalla: joko ne rakentavat oman erillisen käyttäjähakemistonsa, jonka jonkun on täytettävä ja ylläpidettävä, tai ne perivät kyseiset tiedot suoraan järjestelmästä, jota yritys jo käyttää. Ensimmäinen lähestymistapa tarkoittaa todellista asennustyötä: jokaisen työntekijän käyttöoikeuksien määrittämistä manuaalisesti tai integraation rakentamista tilien automaattista synkronointia varten. Juuri tällainen tehtävä päätyy lopulta IT-tiimin pöydälle riippumatta siitä, miten myyntikeskustelussa asiaa on esitetty.

Toinen tapa on kertakirjautuminen (single sign-on). Jotta työntekijät voivat kirjautua sisään jo käyttämillään tunnuksilla sen sijaan, että heidän pitäisi luoda ja muistaa uusi salasana, vaaditaan yleensä yhteyden määrittäminen intranetin ja yrityksen olemassa olevan identiteetin tarjoajan välille. Tämä on aitoa teknistä asennustyötä, ja se mainitaan toimittajan ohjeissa usein ”nopeana konfigurointivaiheena”, vaikka sen oikea suorittaminen vaatii silti henkilöä, jolla on todellista teknistä osaamista.

Kolmas on sisällön siirto ja rakenne. Jopa alusta, jolla ei ole monimutkaista taustatyötä, voi silti vaatia merkittävää IT-taustaista työtä, jos varsinaisen sivurakenteen, mallipohjien ja käyttöoikeuksien määrittäminen edellyttää teknistä skriptausta tai massatietojen käsittelyä, jotta homma saadaan käyntiin. Alusta, joka vaatii hallintakonsolien ja konfiguraatiotiedostojen käytöstä perillä olevan henkilön jopa intranetin alkuperäisen version rakentamiseen, on käytännössä vain siirtänyt IT-riippuvuuden kirjautumissivulta sisältötasolle.

Happeo, jonka käyttöönotto ei vaadi toista järjestelmää

Happeo käsittelee näitä kolmea seikkaa suoraan, pääasiassa välttämällä niitä sen sijaan, että ratkaisisi ne. Yritykselle, joka jo käyttää Google Workspacea tai Microsoft 365:tä, Happeon liittäminen olemassa olevaan ympäristöön on opastettu, konsulttien tukema prosessi sen sijaan, että se olisi projekti, jonka sisäisen IT-tiimin täytyy itse skriptoida ja hallinnoida. Tämä on mahdollista nimenomaan siksi, että Happeo ei rakenna erillistä tunnistus- tai käyttöoikeusjärjestelmää, jota pitäisi täyttää tiedoilla. Se perii molemmat suoraan siitä, mitä yrityksellä on jo käytössä, joten käyttäjähakemistoa ei tarvitse rakentaa, manuaalista käyttöönottoa ei tarvita eikä erillistä järjestelmää, jota pitäisi jatkossa pitää synkronoituna yrityksen todellisten tunnistustietojen kanssa.

Yhden kirjautumisen toiminta perustuu samaan periaatteeseen. Työntekijät kirjautuvat Happeoon samoilla Google- tai Microsoft-tunnuksilla, joita he jo käyttävät sähköpostin ja tiedostojen tallennukseen. Tämä tarkoittaa, ettei kukaan joudu määrittämään, vianmäärittämään tai selittämään hämmentyneille työntekijöille erillistä todennusjärjestelmää käyttöönoton aikana. Tämä yksi suunnitteluvalinta poistaa sen, mikä on tyypillisesti yksi teknisesti monimutkaisimmista osista minkä tahansa intranetin käyttöönotossa, yksinkertaisesti jättämällä kokonaan ottamatta käyttöön toista järjestelmää, joka sitä alun perin edellyttäisi.

Sisällön ja rakenteen osalta Happeo toimitetaan valmiilla, jäsennellyillä malleilla henkilöstöhallintoa, perehdyttämistä, IT-käytäntöjä ja muita yleisiä kategorioita varten, joten yrityksen ei tarvitse aloittaa tyhjältä pöydältä tai tarvita teknistä osaamista omaavaa henkilöä luomaan tietorakennetta. Sivut, tilat ja kanavat tarjoavat selkeän oletuskehyksen tiedon järjestämiselle, ja sivujen luominen tai muokkaaminen tapahtuu suoraviivaisen vedä ja pudota -työkalun avulla, jota viestinnän tai HR:n yleistehtävissä toimiva henkilö voi käyttää suoraan ilman, että alustan käyttöönottoon tarvitaan kehityskokemusta tai hallintakonsolin tuntemusta.

Tätä asennuksen osaa kannattaa tarkastella erityisen tarkasti, koska juuri tässä vaiheessa alustan väite ”ei vaadi IT-osaamista” joko pitää paikkansa tai romahtaa hiljaa. Kun teknisesti kokematon ylläpitäjä ryhtyy ensimmäistä kertaa rakentamaan tilaa tai suunnittelemaan sivua, ero vedä ja pudota -käyttöliittymän ja sellaisen ratkaisun välillä, joka vaatii HTML:n, CSS:n tai käyttöoikeuskonsoleiden käsittelyä, on ratkaiseva. Happeon sivunrakentaja toimii samalla tavalla kuin diaesitys tai yksinkertainen verkkosivunrakentaja: järjestelmänvalvoja lisää teksti-, kuva-, upotettujen tiedostojen tai linkkien lohkoja, järjestää ne visuaalisesti ja näkee tuloksen päivittyvän reaaliajassa ilman, että hänen tarvitsee kirjoittaa koodia tai pyytää kenenkään muun apua ulkoasun saamiseksi näyttämään hyvältä. Uuden kanavan luominen tiimin päivityksiä varten noudattaa samaa logiikkaa: muutama napsautus riittää sen määrittämiseen ja julkaisemisen aloittamiseen, eikä tarvita konfigurointivaihetta, joka pitäisi ohjata järjestelmänvalvojan kautta.

Käyttöoikeuksien määrittäminen – eli sen päättäminen, kuka voi tarkastella tai muokata sisältöä – tapahtuu samanlaisen suoraviivaisen valikon kautta, eikä erillisen pääsynhallintajärjestelmän kautta, joka edellyttää ymmärrystä alustan taustarakenteesta. Tuloksena on, että sisäisestä viestinnästä tai HR-sisällöstä tosiasiallisesti vastaava henkilö voi rakentaa, muokata ja ylläpitää intranetin rakennetta itse alusta alkaen sen sijaan, että joutuisi lähettämään pyynnön ja odottamaan, että joku muu tekee muutoksen.

Happeo on jäsentänyt tämän viisivaiheiseksi käyttöönottoprosessiksi, jota sisäisesti kutsutaan toisinaan HAPPY-menetelmäksi: yrityksen erityistavoitteiden ymmärtäminen, sisältörakenteen muotoilu, alustan rakentaminen ja sisäisen tiimin kouluttaminen, pilotointi varhaiskäyttäjien kanssa sekä täysimittainen käyttöönotto, jossa vastuu siirretään selkeästi eteenpäin. Jokaista vaihetta tukee oma käyttöönottokonsultti, mikä on erityisen tärkeää yrityksille, joilla ei ole omia IT-resursseja, sillä se tarkoittaa, että tarvittavat tekniset päätökset hoitaa joku Happeon edustaja
Happeon edustaja hoitaa ne, eikä yrityksen tarvitse hankkia kyseistä asiantuntemusta talon sisältä. Useimmilla asiakkailla tämä prosessi vie kokonaisuudessaan kuudesta kahdeksaan viikkoa, ilman että IT-osaston jatkuvaa osallistumista tarvitaan missään vaiheessa.

Käyttöönoton jälkeiset tapahtumat ovat yhtä tärkeitä kuin itse käyttöönotto, ja juuri tässä vaiheessa väite IT-riippumattomuudesta joko pitää paikkansa tai romahtaa hiljaa. Alusta, joka on helppo ottaa käyttöön, mutta joka vaatii teknistä ylläpitäjää jokaiseen jatkuvaan sisällönmuutokseen, ei ole todellisuudessa ratkaissut perimmäistä ongelmaa, sillä IT-riippuvuus ilmenee vasta muutaman viikon kuluttua sen sijaan, että se ilmenisi jo alkuperäisen käyttöönoton aikana.

Happeo välttää tämän antamalla sisällön omistajuuden ja muokkausoikeudet niille, jotka sisällön todella luovat. Tietyt sivut ja tilat voidaan osoittaa tietyille tiimeille, ja automatisoidut sisällön kunnonvalvontatyökalut merkitsevät sivut, jotka ovat vanhentuneet tai menettäneet selkeän omistajan, hoitaen merkittävän osan jatkuvasta ylläpitotyöstä, joka muuten jäisi sen vastuulle, joka jää hoitamaan alustaa, kun käyttöönoton innostus on laantunut. Minkään tämän hallinnointi ei vaadi teknistä taustaa.

Tulokset näkyvät todellisessa käytössä. Happeon keskimääräinen viikoittainen käyttöaste asiakaskunnassa on noin 78 %, mikä on yrityksen mukaan selvästi yli sosiaalisten intranet-alustojen tyypillisen noin 31 %:n keskimääräisen käyttöasteen, vaikka tämä vertailu perustuu Happeon omiin julkaisemiin tietoihin eikä riippumattomaan tutkimukseen. Mitä voidaan riippumattomasti todentaa, on alustan maine todellisten käyttäjien keskuudessa: G2-sivustolla se on saanut yli 150 arvostelun perusteella arvosanan 4,5 viidestä, ja 95 % arvostelijoista on antanut sille 4 tai 5 tähteä eikä yhtään yhden tähden arvostelua ole kirjattu. Tämä on vahva ja johdonmukainen tulos kategoriassa, jossa kömpelö asennus ja joustamattomat hallintavaatimukset ovat yleisiä valituksenaiheita.

Mitä kysyä toimittajilta ennen sopimuksen allekirjoittamista

Myyntiesittelyt on suunniteltu esittelemään alusta parhaimmillaan, minkä vuoksi on helppo saada vaikutelma, että ”IT-osaamista ei tarvita” – vaikutelma, joka ei kestä ensimmäistä kosketusta todellisen käyttöönoton kanssa. Muutama suora kysymys auttaa yleensä erottamaan aidon IT-riippumattomuuden väitteestä, joka pitää paikkansa vain esittelyssä.

Kannattaa kysyä erityisesti: ylläpitääkö alusta omaa käyttäjähakemistoaan, vai periiikö se tunnistetiedot ja käyttöoikeudet suoraan yrityksen olemassa olevasta Google Workspace- tai Microsoft 365 -asennuksesta. Toimittaja, jonka on selitettävä erillinen käyttöönottoprosessi – vaikka se olisi yksinkertaistettu – kuvailee järjestelmää, johon liittyy jatkuvia IT-kustannuksia, riippumatta siitä, miten nämä kustannukset esitetään.

Kannattaa kysyä, kuka määrittää kertakirjautumisen (SSO) ja onko kyseessä kertaluonteinen asetusvaihe vai jotain, joka vaatii säännöllistä huomiota, kun yrityksen identiteetin tarjoaja muuttuu ajan myötä. Toimittaja, joka mainitsee tukipyynnön tai teknisen yhteyshenkilön SSO:n vianmääritykseen, kertoo sinulle epäsuorasti, että järjestelmä ei ole täysin IT-riippumaton.

Kannattaa pyytää nähdä varsinainen sivunrakennusliittymä, ei pelkästään valmiita esimerkkejä.

Ero ”voit luoda sivuja helposti” -väittämän ja sen välillä, että katsot, kuinka joku ilman teknistä taustaa todella luo sivun reaaliajassa siirtymättä toiseen työkaluun tai kutsumatta järjestelmänvalvojaa apuun, on usein paljastava. Jos toimittaja ei voi tai halua näyttää tätä vaihetta suoraan, kannattaa tulkita tätä haluttomuutta merkiksi.

Kannattaa kysyä, mitä sivulle tapahtuu, kun sen luonut henkilö vaihtaa tehtävää tai lähtee yrityksestä. Siirtyykö omistajuus automaattisesti, merkitäänkö sisältö jotenkin tarkistettavaksi vai jääkö se vain odottamaan, kunnes joku lopulta huomaa sen olevan vanhentunut? Tämä kysymys paljastaa usein, onko alusta todella suunniteltu pitkäaikaista, IT-osaamista vaativaa ylläpitoa silmällä pitäen vai onko ainoastaan asennuksen helppous optimoitu.

Kannattaa myös pyytää referenssiasiakkaita, jotka ovat nimenomaan kooltaan ja teknisiltä resursseiltaan samanlaisia kuin oma yrityksesi, eikä pelkästään toimittajan suurinta tai eniten tukea saavaa asiakasta. Alusta, joka toimii hyvin yrityksessä, jolla on oma intranet-henkilöstö, ei välttämättä toimi samalla tavalla yrityksessä, jolla ei ole lainkaan IT-toimintoa.

Miltä todellinen IT-riippumattomuus näyttää

Selkein testi sille, välttääkö alusta todella IT-riippuvuuden, on se, mitä tapahtuu puolitoista vuotta myöhemmin, kun alkuasennuksen tehnyt henkilö on siirtynyt toiseen projektiin – eikä se, mitä myyntipuheessa luvataan. Alustat, jotka ovat hiljaa rakentaneet toisen tunnistusjärjestelmän, erillisen käyttöoikeusrakenteen tai teknistä osaamista vaativan sisällönhallinnan, muuttuvat lopulta yleensä IT-osaston ongelmaksi, riippumatta siitä, oliko se alkuperäinen suunnitelma vai ei.

Yritykselle, joka käyttää jo Google Workspacea tai Microsoft 365:tä, Happeo välttää tämän lopputuloksen nimenomaan siksi, ettei se ole alun perinkään ollut toinen järjestelmä. Asennus nojaa jo olemassa olevaan infrastruktuuriin sen sijaan, että se vaatisi useita viikkoja kestävää teknistä projektia, jatkuva sisällönhallinta jää sen luojien vastuulle sen sijaan, että se kulkisi järjestelmänvalvojan kautta, ja alustan omat käyttö- ja arviointitiedot viittaavat siihen, että tämä malli toimii hyvin myös alkuperäisen käyttöönoton jälkeen. Tämä on merkittävästi erilainen väite kuin se, että alusta vain mainostaa itseään helppokäyttöiseksi, sillä se perustuu siihen, mitä teknisesti on todella tapahduttava ennen kuin kukaan voi kirjautua sisään – ei pelkästään siihen, miltä käyttöliittymä näyttää kirjautumisen jälkeen.

Usein kysyttyjä kysymyksiä

Voiko yritys ottaa intranetin käyttöön ilman minkäänlaista IT-osaston osallistumista? Pääosin kyllä, edellyttäen että alusta on rakennettu perimään tunnistetiedot ja käyttöoikeudet olemassa olevasta järjestelmästä sen sijaan, että se luo omat. Käyttöönoton aikana tulee silti esiin joitakin teknisiä harkintapäätöksiä, minkä vuoksi ohjattu käyttöönottoprosessi erikoistuneen konsultin avustuksella toimii yleensä paremmin kuin oletus, että viestintä- tai HR-tiimi pystyy hoitamaan kaikki poikkeustapaukset täysin yksin.

Kuka yleensä vastaa intranetistä, kun se on IT-osastosta riippumaton? Yleensä sisäisen viestinnän, henkilöstöhallinnon tai vastaavan yleistoiminnon edustajat, ei IT-osasto. Alustan suunnittelu ratkaisee, onko tämä kestävä ratkaisu: jos sivujen luominen, käyttöoikeuksien hallinta ja omistajuuden määrittäminen tapahtuvat kaikki ei-teknisillä käyttöliittymillä, kyseinen tiimi voi realistisesti ylläpitää alustaa itsenäisesti vielä pitkään käyttöönoton jälkeenkin.

Tarkoittaako IT-osaston osallistumisen välttäminen turvallisuuden tai hallinnon uhraamista? Ei, jos alusta perii käyttöoikeusrakenteensa yrityksen olemassa olevasta tunnistusjärjestelmästä. Turvallisuus tällaisessa kokoonpanossa on yhtä vahva kuin jo käytössä oleva Google Workspace- tai Microsoft 365 -kokoonpano, jota ylläpidetään tyypillisesti korkeammalla tasolla kuin nimenomaan intranetiä varten rakennettua räätälöityä järjestelmää.

Kuinka kauan tyypillinen IT-osaston osallistumatta toteutettu käyttöönotto kestää? Tällaisen natiivin integraation ympärille rakennettujen alustojen osalta useimmat asiakastoteutukset kestävät Happeon omien raportoitujen käyttöönottotietojen mukaan noin kuudesta kahdeksaan viikkoa aloituksesta täyteen käyttöönottoon. Tämä aikataulu sisältää sisällön jäsentelyn ja sisäisen tiimin kouluttamisen, ei pelkästään itse teknistä liittämistä.