Hjertet av internsystemet, Min side, er proppet fullt med masse forskjellige funksjonaliteter som arrangementer, webshop, lønn, aksjer, goder, økonomi, forsikringsdokumenter, info om ansatte osv, osv. Det vil si, funksjonalitetene eksisterer i sine representative microservice-apper, men Min side knytter disse sammen til et felles sted. Dette er en relativt vanlig arkitektur for større systemer da det tillater appene å kjøre for seg selv også utenfor koblingen til Min side. På denne måten kan vi utnytte det beste av to verdener - samle all funksjonalitet til Snøkam-ansatte på ett sted, samtidig som vi kan eksponere de appene vi ønsker også til personer utenfor Snøkam. Fra venstremenyen i skjermbildet så kan vi se at Min side router til veldig mange ressurser - både interne, men også eksterne. Vi skal titte innom noen av de i denne bloggposten, men mange av de er såpass innholdsrike og spennende at vi skal dedikere helt egne poster til dem.

Før vi hopper inn i noe av funksjonene i menyen så skal vi ta for oss resten av det man ser i skjermbildet. Dette er altså landingssiden, og det alle ser når man logger inn - en plass for det aller viktigste. Her henter vi inn starten av CVen til den innloggede slik at man skal ha et tettere forhold til hvordan kunnskapsprofilen ser ut. Det er viktig for Snøkam som et selskap at alle ansatte eier det som står i egen CV, og ved å liste dette opp som det første man ser, så tror vi på at knytningen skapes allerede her. Noe annet som er viktig er tilfredshet. En slider kan brukes om det er noe som ikke er helt som det skal være, så er dette et enkelt tiltak for å senke terskelen til å si ifra om det er noe som ikke er 100%. Om man kunne scrollet nedover i skjermbildet ville man så sett hele visjonen til Snøkam uttrykt i OKRer (Objectives and Key Results) - altså det vi jobber for og mot hver eneste dag.

La oss se på litt av det i menyen:

Håndbok

Jeg har lyst til å starte med håndboka, fordi dette er et enkelt konsept og som derfor også enkelt kan forklares teknisk. Denne er tilgjengelig både via Min side, men også eksternt til alle som besøker handbok.snokam.no.

Når man lager en statisk side som dette er det viktig å tenke på hvordan en redaktør skal bruke den. Man ønsker ikke å være avhengig av en utvikler når brukeroppgavene alltid er å legge til, endre eller fjerne tekst. Stort sett er alltid svaret her en form for CMS (Content Management System), som også naturlig nok er tilfellet her. Koden legger derfor tilrette for tekst, funksjonalitet som tilgangsstyring, seksjoner og styling. Nå som utviklingen hos oss er på plass, så kan alle redaktører gå inn i CMSet og enkelt legge til nye seksjoner eller endre eksisterende.

Håndboken er også et perfekt eksempel hvor SSR (Server Side Rendring) gir veldig mening. En håndbok oppdateres sjeldent og SSR med Next.js gir en svært enkel cache-håndtering av håndboka som gjør at man ikke trenger å belaste endepunktene mer enn nødvendig. Dette gir en lynrask nettside, god SEO (Search Engine Optimisation, så Google finner nettsiden enklere), og også skjulte API-kall.

Sammen med SSR og autentisering har vi lagt til rette for å sette tilgangsstyring på enkelte seksjoner som kun gir mening for Snøkam-ansatte. Dette kan være detaljer som hvilken timekode man skriver sykdom på, eller forsikringspolise. Tilgangsstyringen gir oss derfor to fordeler ved å både fjerne unødvendig informasjon til eksterne interesserte lesere, og også hindre at hemmeligheter blir eksponert.

Slik er håndboka designet for å kunne vises både internt og eksternt, og som en ekstra bonus har vi derfor trukket dette ut som et eget komponent! Det gjør det ekstremt enkelt å vise hele håndboka hvor enn vi ønsker, men bare et par linjer med kode per sted. Håndbok kan være noe tørt og kjedelig, men teknologien som ligger bak er ganske spennende når man har bygd løsningen på en teknisk elegant måte.

Håndboka fra handbok.snokam.no

Webshop

Hvem liker vel ikke litt merch? I vår helt egne webshop kan ansatte bestille alt fra klær til tøfler. Et år kunne man til og med bestille hint til lokasjonen av julebordet her!

Selv om webshopper finnes som SaaS (Software as a Service) mange steder, ønsket vi å starte med noe som var veldig enkelt og heller skreddersydd inn i internsystemet og datasentralen. Behovet vårt var enkelt, vi ville ha et sted som enkelt viste hvilke merch vi skulle gå til innkjøp av, hente hvor mange eksemplarer i hver størrelse vi trengte, og til slutt holde styr over hvilke varer de forskjellige skulle få. Etter hvert som veien gikk, ble selvfølgelig scopet utvidet, og i dag er hele webshopen også knyttet inn mot Snøkams godesystem.

Når en ny vare skal gjøres tilgjengelig i webshopen så oppretter vi enten et nytt element (eller finner det eksisterende) i vårt CMS. Her styres alt fra tilgjengelighet i webshopen, hvilke størrelser man skal kunne velge og hvilke vi har på lager, bilder osv. Backenden vår er i tillegg integrert med Snøkam-slacken slik at alle nye bestillinger også trigges i det interne kommunikasjonssystemet.

Ved utlevering kan merch-ansvarlig prosessere bestillingene som automatisk oppdaterer varebeholdning, rydder opp i ordrene, og tilknytter varen til årets godebudsjett. På denne måten kan vi håndtere det økonomiske, varebeholdning og innhold svært enkelt og automatisert. Det som er kult med å ha en egeneid webshop på denne måten (og ikke gjennom SaaS) er at vi kan bruke dataene våre på en mye enklere og innsiktsfull måte. Alle ansatte i Snøkam har derfor en komplett liste over alle merch, da alt blir registrert på samme sted i CMSet. Enten man har løpe-t-skjorte til Holmenkollstafetten, fått en Mac ved oppstart eller bestilt tøfler i webshopen så er alt lagret på samme plass og visualiseres gjennom godesystemet.

Enkel adminhåndtering for å prosessere Vegard sin t-skjorte

Godesystemet

Når man nevner A, så må man også si B. Fleksibilitet blir sett på som en gode i seg selv, så hvorfor ikke implementere et hel-fleksibelt godesystem som man selv kan bestemme hvordan forvaltes? Målet er å lage en så rettferdig løsning som mulig, slik at om man ønsker å bruke penger i webshopen eller på gadgets, så blir alt støttet fra samme plass. Webshop-artikler tilegnes automatisk inn på prosessering, mens godesystem-utlegg hentes rett ned fra regnskapssystemet. I arkitekturen vår har vi opprettet en backend-app (eller Azure Function for den tekniske) dedikert til synkronisering av alle mulige slags data - og da også utlegg fra PowerOffice (regnskapssystemet). Sync-function sjekker hver dag om nye utlegg er registrert ved å kalle vårt api i power-office-function. Eventuelle utlegg registreres deretter inn i Godesystemet som lagres i CMSet.

Det beste med denne løsningen er faktisk hvordan den er teknisk organisert, ved at vi hele tiden har single source of truth! Siden alle godene synces fra PowerOffice vill regnskapet være dataeieren, slik at vi kan sørge for at ingen kostnader går tapt og revisorer og skatteetater forblir fornøyde. Om man hadde gått for en snarvei, så kunne man bare registrert dette direkte inn i CMSet. Men hva gjør man da om data går tapt, eller om en sum ble lagt inn feil? Å fjerne slike røtter til usikkerhet er viktig i en automatisert verden, og derfor noe vi selvsagt har stort fokus på når vi automatiserer alle prosessene som vi gjør.

Et lite innsyn i hvordan alle goder slås sammen i internsystemet

Vi har tatt en rask titt inn i noe av det som finnes fra Min side, men det er ingen tvil om at det er mange udekte tjenester igjen i internsystemet! Heldigvis, og som nevnt i innledningen, så er det bare å følge med videre - så kommer vi til å komme til bunns også i de senere i artikkelserien!

I Episode 1 så vi en arkitektur over hele internsystemet. Systemene vi touchet borti i løpet av denne bloggposten er markert i grønt.