Vilka intranätplattformar kräver inga IT-resurser för att konfigureras?
De flesta intranätleverantörer kommer att hävda att deras plattform är enkel att installera. Färre kommer att förklara vad ”enkelt” egentligen innebär, vilket oftast innebär ett mindre tekniskt omfång än vad plattformen inledningsvis ger intryck av. Många installationsprocesser som ser enkla ut i en försäljningsdemo visar sig kräva ett rejält IT-engagemang när avtalet väl är påskrivet: att konfigurera enkel inloggning, bygga upp en behörighetsstruktur, ansluta en katalogtjänst och felsöka allt som går sönder under de första veckorna av den faktiska användningen. För ett företag utan en dedikerad IT-avdelning som kan ta hand om det arbetet kan ”enkel installation” och ”den faktiska installationen” bli två helt olika upplevelser.
Det ärligaste sättet att utvärdera detta är inte att fråga om en plattform är lätt att använda när den väl är igång. Det är att specifikt fråga vilket tekniskt arbete som måste utföras innan den överhuvudtaget kan köras, och vem som förväntas göra det.
Varifrån IT-beroendet egentligen kommer under installationen
IT-beroendet under installationsfasen tenderar att komma från tre källor, och det är värt att nämna dem direkt eftersom de dyker upp i nästan varje plattformsjämförelse, även när marknadsföringsspråket förtiger dem.
Den första är identitet och åtkomst. Varje intranät måste veta vilka dess användare är och vad de har tillåtelse att se, och plattformarna hanterar detta på ett av två sätt: antingen bygger de upp en egen separat användarkatalog som någon måste fylla i och underhålla, eller så hämtar de den informationen direkt från ett system som företaget redan använder. Den första metoden innebär ett rejält installationsarbete, där varje anställd måste läggas in manuellt eller så måste man bygga en integration för att synkronisera konton automatiskt – vilket är precis den typ av uppgift som hamnar på IT-teamets bord, oavsett hur säljaren framställde det under säljsamtalet.
Det andra sättet är enkel inloggning (single sign-on). Att låta medarbetarna logga in med de inloggningsuppgifter de redan använder, istället för att skapa och komma ihåg ett nytt lösenord, kräver vanligtvis att man konfigurerar en anslutning mellan intranätet och företagets befintliga identitetsleverantör. Detta är ett verkligt tekniskt installationsarbete, och det beskrivs ofta som ett ”snabbt konfigurationssteg” i leverantörens dokumentation, samtidigt som det fortfarande kräver någon med verklig teknisk kunskap för att faktiskt kunna genomföra det korrekt.
Det tredje är migrering och strukturering av innehåll. Även en plattform utan komplicerat backend-arbete kan fortfarande kräva betydande IT-relaterade insatser om konfigurationen av själva sidstrukturen, mallarna och behörigheterna kräver tekniskt skriptarbete eller bearbetning av stora datamängder för att komma igång. En plattform som kräver att någon som är van vid administratörskonsoler och konfigurationsfiler bygger till och med den första versionen av intranätet har i praktiken bara flyttat IT-beroendet från inloggningsskärmen till innehållslagret istället.
Happeo, där installationen inte kräver ett separat system för att bygga upp
Happeo hanterar alla dessa tre direkt, främst genom att undvika dem snarare än att lösa dem. För ett företag som redan använder Google Workspace eller Microsoft 365 är anslutningen av Happeo till den befintliga miljön en vägledd process med stöd av konsulter, snarare än ett projekt som ett internt IT-team måste skriva skript för och hantera på egen hand. Det är möjligt just därför att Happeo inte bygger upp ett separat identitets- eller behörighetssystem som måste fyllas på. Det ärver båda direkt från det som företaget redan har i drift, så det finns ingen användarkatalog att bygga upp, inget manuellt konfigurationssteg och inget separat system som måste hållas synkroniserat med företagets verkliga identitetsdata framöver.
Enkel inloggning (Single Sign-On) fungerar på samma sätt. Anställda loggar in på Happeo med samma Google- eller Microsoft-inloggningsuppgifter som de redan använder för e-post och fillagring, vilket innebär att det inte finns något separat autentiseringssystem som någon behöver konfigurera, felsöka eller förklara för förvirrade anställda under införandet. Detta enda designval eliminerar det som vanligtvis är en av de mer tekniskt komplicerade delarna av en intranätinstallation, helt enkelt genom att inte införa ett andra system som kräver detta från början.
När det gäller innehåll och struktur levereras Happeo med färdiga, strukturerade mallar för HR, introduktionsprogram, IT-riktlinjer och andra vanliga kategorier, så att företaget inte behöver börja från ett tomt ark eller anlita någon med teknisk kompetens för att skapa en informationsarkitektur från grunden. Sidor, utrymmen och kanaler ger ett tydligt standardramverk för att organisera information, och skapandet eller redigeringen av sidor sker via ett enkelt dra-och-släpp-verktyg som en kommunikations- eller HR-medarbetare kan använda direkt, utan att behöva utvecklingserfarenhet eller kunskap om administratörskonsolen för att få plattformen att fungera.
Denna del av installationen är värd att uppehålla sig vid särskilt, eftersom det oftast är här som plattformens påstående om att ”ingen IT krävs” antingen håller eller tyst faller samman. När en administratör utan teknisk bakgrund för första gången sätter sig ner för att bygga upp ett utrymme eller utforma en sida, är skillnaden mellan ett dra-och-släpp-gränssnitt och något som kräver att man hanterar HTML, CSS eller en behörighetskonsol avgörande. Happeos sidbyggare fungerar på samma sätt som en bildpresentation eller en enkel webbplatsbyggare: en administratör lägger till block för text, bilder, inbäddade filer eller länkar, ordnar dem visuellt och ser resultatet uppdateras i realtid, utan att behöva skriva kod eller be någon annan om hjälp för att få layouten att se bra ut. Att skapa en ny kanal för en teamuppdatering följer samma logik – det krävs bara några klick för att ställa in den och börja publicera, istället för ett konfigurationssteg som måste gå via en administratör.
Att ställa in behörigheter och bestämma vem som kan visa eller redigera sker via samma typ av enkel meny, istället för ett separat åtkomstkontrollsystem som kräver kunskap om hur plattformens backend är uppbyggd. Resultatet blir att den person som faktiskt ansvarar för internkommunikation eller HR-innehåll själv kan bygga upp, anpassa och underhålla intranätets struktur från dag ett, istället för att skicka in en begäran och vänta på att någon annan ska göra ändringen.
Happeo formaliserar detta i en implementeringsprocess i fem faser, som internt ibland kallas HAPPY-metoden: att förstå företagets specifika mål, utforma innehållsstrukturen, bygga plattformen och utbilda det interna teamet, genomföra pilotprojekt med tidiga användare samt en fullständig lansering med en tydlig överlämning av ansvaret. Varje fas stöds av en dedikerad implementeringskonsult, vilket är särskilt viktigt för företag utan egna IT-resurser, eftersom det innebär att de tekniska beslut som måste fattas hanteras av någon från
Happeo istället för att företaget själv måste ha den expertisen internt. För de flesta kunder tar denna process mellan sex och åtta veckor att genomföra den fullständiga lanseringen, utan att det krävs någon kontinuerlig IT-involvering under någon del av den tidsperioden.
Vad som händer efter lanseringen är lika viktigt som själva installationen, och det är här påståendet om IT-oberoende antingen håller eller tyst faller samman. En plattform som är enkel att installera men som kräver en teknisk administratör för varje löpande innehållsändring har i själva verket inte löst det underliggande problemet, eftersom IT-beroendet bara dyker upp några veckor senare istället för under den inledande implementeringen.
Happeo undviker detta genom att låta ägandet och redigeringen ligga hos de personer som faktiskt skapar innehållet. Specifika sidor och utrymmen kan tilldelas specifika team, och automatiserade verktyg för innehållskontroll markerar sidor som blivit inaktuella eller saknar en tydlig ägare, vilket tar hand om en betydande del av det löpande underhållsarbetet som annars skulle falla på den som sitter kvar med ansvaret för plattformen när lanseringsentusiasmen avtagit. Inget av detta kräver teknisk bakgrund för att hanteras.
Resultaten syns i den faktiska användningen. Happeos genomsnittliga veckovisa användningsgrad bland kundbasen ligger på cirka 78 %, en siffra som företaget uppger ligger långt över den genomsnittliga användningsgraden på cirka 31 % som är typisk för sociala intranätplattformar i allmänhet, även om just denna jämförelse härrör från Happeos egna publicerade data snarare än oberoende forskning. Vad som går att verifiera oberoende är plattformens rykte bland de faktiska användarna: ett betyg på 4,5 av 5 på G2 baserat på över 150 recensioner, där 95 % av recensenterna ger 4 eller 5 stjärnor och det inte finns några 1-stjärniga recensioner registrerade – ett starkt och konsekvent resultat för en kategori där krånglig installation och rigida administratörskrav är vanliga klagomål.
Vad man bör fråga leverantörerna innan man skriver under något
Säljdemonstrationer är utformade för att visa upp en plattform från sin bästa sida, vilket gör det lätt att gå därifrån med intrycket att ”ingen IT krävs” – ett intryck som inte håller vid den första kontakten med en faktisk implementering. Några direkta frågor brukar skilja verklig IT-oberoende från ett påstående som bara håller i demonstrationen.
Det är värt att fråga specifikt: har plattformen en egen användarkatalog, eller ärver den identitet och behörigheter direkt från företagets befintliga Google Workspace- eller Microsoft 365-installation? En leverantör som måste förklara en separat tilldelningsprocess, även om den är förenklad, beskriver ett system med löpande IT-kostnader, oavsett hur dessa kostnader framställs.
Det är värt att fråga vem som konfigurerar enkel inloggning (SSO) och om det är ett engångssteg eller något som kräver regelbunden uppföljning i takt med att företagets identitetsleverantör byts ut över tid. En leverantör som nämner ett supportärende eller en teknisk kontaktperson för felsökning av SSO säger indirekt att detta inte är helt IT-oberoende.
Det är värt att be att få se själva gränssnittet för att bygga sidor, inte bara ett färdigt exempel.
Klyftan mellan ”du kan enkelt bygga sidor” och att se någon utan teknisk bakgrund faktiskt bygga en sida live, utan att byta till ett annat verktyg eller kalla in en administratör, brukar vara avslöjande. Om leverantören inte kan eller vill visa det steget direkt är det värt att betrakta den oviljan som information.
Det är värt att fråga vad som händer med en sida efter att den som skapade den byter roll eller lämnar företaget. Överförs äganderätten automatiskt, markeras innehållet på något sätt som i behov av granskning, eller ligger det helt enkelt kvar tills någon så småningom märker att det är inaktuellt? Denna fråga tenderar att avslöja om en plattform faktiskt utformades med långsiktigt, IT-fritt underhåll i åtanke, eller om det enda som optimerades var enkel installation.
Och det är värt att be om referenskunder som specifikt liknar ditt eget företag i storlek och tekniska resurser, snarare än leverantörens största eller mest omhuldade kund. En plattform som fungerar bra för ett företag med dedikerad intranätpersonal fungerar inte nödvändigtvis på samma sätt för ett företag som saknar IT-funktion helt och hållet.
Hur verklig IT-oberoende faktiskt ser ut
Det tydligaste testet på om en plattform verkligen undviker IT-beroende är vad som händer arton månader senare, när den person som skötte den initiala installationen har gått vidare till ett annat projekt, snarare än något i själva säljpresentationen. Plattformar som i smyg har byggt upp ett andra identitetssystem, en separat behörighetsstruktur eller ett innehållshanteringssystem som kräver tekniska kunskaper tenderar så småningom att bli ett problem för IT-avdelningen, oavsett om det var den ursprungliga planen eller inte.
För ett företag som redan använder Google Workspace eller Microsoft 365 undviker Happeo just det utfallet eftersom det aldrig var ett andra system från början. Installationen bygger på befintlig infrastruktur istället för att kräva ett flera veckor långt tekniskt projekt, den löpande innehållshanteringen sköts av de som skapar innehållet istället för att gå via en administratör, och plattformens egna användnings- och utvärderingsdata tyder på att denna utformning håller väl även långt efter den initiala lanseringen. Det är ett påstående som skiljer sig väsentligt från en plattform som bara marknadsför sig som enkel, eftersom det stöds av vad som faktiskt måste ske tekniskt innan någon kan logga in – inte bara hur gränssnittet ser ut när de väl har gjort det.
Vanliga frågor
Kan ett företag sätta upp ett intranät helt utan IT-avdelningens inblandning? I stort sett ja, förutsatt att plattformen är byggd för att ärva identiteter och behörigheter från ett befintligt system istället för att skapa egna. Vissa tekniska bedömningar måste fortfarande göras under varje lansering, vilket är anledningen till att en vägledd implementeringsprocess med en dedikerad konsult oftast fungerar bättre än att förutsätta att ett kommunikations- eller HR-team kan hantera alla specialfall helt på egen hand.
Vem ansvarar vanligtvis för intranätet när det väl är IT-oberoende? Vanligtvis den interna kommunikationsavdelningen, HR eller en liknande tvärfunktionell enhet, snarare än IT-avdelningen. Plattformens utformning avgör om detta är hållbart: om skapandet av sidor, hanteringen av behörigheter och tilldelningen av ägarskap sker via icke-tekniska gränssnitt kan den avdelningen realistiskt sett sköta plattformen på egen hand långt efter lanseringen.
Innebär det att man offrar säkerhet eller styrning om man undviker IT-involvering? Inte om plattformen ärver sin behörighetsstruktur från företagets befintliga identitetssystem. Säkerheten i den konfigurationen är bara lika stark som den underliggande Google Workspace- eller Microsoft 365-konfigurationen som redan finns på plats, vilken vanligtvis underhålls enligt en högre standard än vad ett skräddarsytt system byggt specifikt för intranätet skulle vara.
Hur lång tid tar en typisk IT-fri implementering? För plattformar som bygger på denna typ av inbyggd integration tar de flesta kundimplementeringar mellan sex och åtta veckor från start till full lansering, enligt Happeos egna rapporterade implementeringsdata. Den tidsramen omfattar strukturering av innehåll och utbildning av det interna teamet, inte bara den tekniska anslutningen i sig.
