Sidene der noen holder systemet i gang: oppretter brukere, styrer hvem som får se hva, og vedlikeholder grunnlagsdataene resten av systemet henter fra. Nesten alltid med, nesten alltid den største modulen — og den som oftest mangler i budsjettet.
Hvem modulen er for
For administratoren — den ansatte som forvalter systemet på vegne av virksomheten. Det er sjelden mange av dem, ofte to–tre personer, og det er nettopp derfor modulen blir undervurdert: få brukere leses som lite arbeid. Men antall brukere sier ingenting om omfang. Omfanget følger av hvor mange ting som kan settes opp, ikke av hvor mange som setter dem opp.
Tilsvarende tilgangsrolle i spesifikasjonen: Administrator (og eventuelle mellomroller som «saksbehandler» eller «redaktør»). En tilgangsrolle er samlingen av rettigheter en bruker får — hva vedkommende har lov til å se og gjøre.
Typisk innhold
Brukeradministrasjon (opprette, deaktivere, tilbakestille passord). Tilgangsstyring — hvilke tilgangsroller finnes, og hva får hver av dem gjøre. Grunnlagsdata: kategorier, satser, produkter, avdelinger, statuser, maler for e-post og varsler — alle listene resten av systemet velger fra. Systemoppsett: logo, kontaktopplysninger, integrasjonsnøkler, åpningstider. Ofte også en revisjonslogg (en logg over hvem som endret hva og når) og import og eksport av data.
Hvorfor den undervurderes
Fordi den er usynlig i salgssamtalen. Når en virksomhet beskriver systemet den ønsker seg, beskriver den det kundene og de ansatte skal gjøre — bestille, søke, registrere, følge opp. Administrasjonen av selve systemet nevnes ikke, fordi den ikke er en forretningsprosess; den er en forutsetning. Så kommer den likevel, fordi ethvert flervalgsfelt i systemet trenger et sted der valgene vedlikeholdes. Regel du kan bruke direkte: hver eneste nedtrekksliste ute i systemet er et lite administrasjonsskjermbilde som ingen har snakket om ennå. Har systemet tjue slike lister, har du tjue skjermbilder du ikke har estimert.
Når det bør være en egen modul
Nesten alltid. Unntaket er systemer uten innlogging og uten redigerbare grunnlagsdata — en ren informasjonsside, eller et verktøy som regner ut noe uten å lagre noe. Så snart systemet har brukere som må opprettes, eller lister som må vedlikeholdes, finnes administrasjonen enten som egen modul eller som noe utviklerne gjør manuelt i databasen. Det siste er ikke en besparelse; det er en regning som kommer senere, som en kostnad ved forvaltning i stedet for en kostnad ved utvikling.
Fallgruver
Å bygge den til slutt. Adminsidene er det systemet trenger for å kunne fylles med data, så bygges de sist får ikke testingen realistiske data, og lanseringen står og venter. Å la utviklerne administrere i stedet — det binder virksomheten til leverandøren for helt trivielle endringer, og er en av de vanligste formene for innlåsing. Å bygge tilgangsstyring finere enn nødvendig: rettigheter på feltnivå høres fremtidsrettet ut, men blir dyrt å bygge og forvirrende å forvalte. Start med et fåtall tilgangsroller. Og til slutt: å glemme at admin også trenger de kjedelige tingene — søk, sortering og eksport. Uten dem blir modulen ubrukelig så snart datamengden vokser.
AI-perspektiv
Adminsider er den delen av et system som ligner mest på seg selv fra prosjekt til prosjekt: lister, skjemaer, søk, rettigheter. Nettopp derfor er det her AI-assistert utvikling gir mest — mønstrene er kjente og lett å generere. Det som ikke blir billigere, er avgjørelsene: hvilke tilgangsroller virksomheten faktisk trenger, hvem som skal kunne slette noe, og hva som må logges for å tåle et tilsyn. Det er de spørsmålene som tar tid i et adminkapittel, og de tar like lang tid som før.
Les mer i utdypende artikkel →
Skal dere sette omfanget på et system? Modulene avgjør hvor stort prosjektet blir, og den største av dem er ofte den ingen har snakket om. DOPS har spesifisert og bygget systemer for norske virksomheter i over 20 år.
Be om et estimat