En ny lagermedarbejder starter på mandag, og et sted i en Teams-tråd står der en sætning som jeg tror findes i næsten alle Business Central-installationer jeg har været inde i: “Kan du ikke lige kopiere rettighederne fra Jens?”
Det er et tænkt eksempel, men kun i den forstand at Jens ikke findes. Sætningen findes.
Jens har været i huset i elleve år. Han var superbruger dengang de gik live, og i hypercare-ugen fik han SUPER, fordi det var hurtigere end at finde ud af hvad han præcis manglede, og fordi der var en deadline på fredag. Han fik også et permission set som en konsulent byggede en onsdag eftermiddag for at løse et konkret problem med lagerreguleringer (og nej, ingen kan længere huske hvad problemet var). Oven i det har han adgang til betalingsforslag, fordi han i en periode passede bogholderiet mens Mette var på barsel. Det er tre år siden.
Når den nye lagermedarbejder får “rettighederne fra Jens”, får hun altså ikke en lagerrolle. Hun får et aflejret lag af elleve års undtagelser, hvor hver enkelt undtagelse var fornuftig den dag den blev lavet. Og når der om fjorten dage starter én mere, bliver hun selv kopieret videre.
Sådan arver et system gæld.
Jeg synes det er værd at holde fast i hvorfor det sker, for det er ikke sjusk. Rettigheder i Business Central lægges sammen: effektive rettigheder er foreningsmængden af alt hvad brugeren har fået tildelt, uanset om det kommer fra brugerkortet, fra en licenskonfiguration eller fra en gruppe. Det eneste rigtige loft er licensen. Der er ikke noget felt hvor man kan sætte et minus, man kan kun undlade at give. En kopi bliver derfor aldrig mindre end originalen, og rettighederne i en installation vokser kun i én retning, indtil nogen sætter sig ned med Effective Permissions og en kop kaffe og går brugerne igennem (det er stadig et kvarter pr. bruger, og der er tres brugere).
Gruppen flytter beslutningen ud af brugerkortet
Mekanikken i security groups er ligetil nok. Du opretter en gruppe i Microsoft Entra, du knytter den til BC på siden Security Groups, du tildeler gruppen de permission sets rollen har brug for, og så følger rettighederne medlemskabet. Der er ikke meget magi i det. Det har ligget i Business Central siden 2023, og for de fleste er det efterhånden ikke engang et valg, for user groups blev fjernet med version 251.
Den umiddelbare gevinst er den man plejer at fremhæve i et salgsslide. Den nye lagermedarbejder bliver lagt i lagergruppen af den samme person som i forvejen opretter hende i Entra og giver hende en licens, og så har hun de rigtige rettigheder første gang hun logger på, uden at nogen skal ind på brugerkortet. Når hun en dag siger op, forsvinder rettighederne fordi medlemskabet forsvinder, og det sker i forvejen som en del af IT-processen. Det er langt sværere at glemme end en oprydning inde i BC, og det er ret smart.
Men automatikken er ikke pointen. I min optik er den vigtigste effekt en anden: gruppen tvinger dig til at navngive rollen.
En gruppe som hedder BC-PROD-Salgssupport er nemlig en påstand om organisationen. Den siger: der findes en funktion i vores hus som skal kunne oprette og ændre ordrer, men ikke prissætte dem, og ikke bogføre dem. Den sætning er der ingen som behøver at formulere så længe rettighederne bor på brugerkortet, for der behøver man kun at svare på hvem den nye ligner mest. Det er et markant lettere spørgsmål, og det er derfor vi alle sammen stiller det.
Hvor dyrt det lette spørgsmål er, går først op for en når revisoren før eller siden stiller sit:
“Hvem hos os kan oprette en kreditor, rette bankkontoen på den og frigive betalingen?”
Det kan man godt svare på når rettighederne ligger pr. bruger, men man kan ikke svare på det i mødet, for svaret ligger to timer længere fremme, ude på den anden side af Effective Permissions, en Excel-fane og en fornemmelse af at man nok har overset en. Ligger rollerne i grupper, er svaret en medlemsliste, og det er den forskel jeg synes betyder mest, mere end onboarding-tiden.
Den opdeling som gør ondt
Når vi taler om at skære grupperne, er de fleste hurtige til at nævne afdelingerne. Finans, lager, salg, indkøb, administration. Det er også det rigtige sted at starte, men problemet ligger sjældent der, for de fem grupper er sådan set bare organisationsdiagrammet skrevet ned én gang til.
Det interessante er den opdeling som ikke findes i organisationsdiagrammet. Salg og salgssupport sidder i de samme dokumenter og har ofte den samme titel på visitkortet, men de har vidt forskellige rettighedsbehov, fordi salgssupport skal kunne oprette ordren og følge leveringen, mens prissætning, kreditnotaer og bogføring hører til det økonomiske skøn som nogen skal stå på mål for. Det er den enkeltopdeling jeg oftest ser blive sprunget over, og også den som koster mest, fordi ordreindtastning er den funktion flest medarbejdere har brug for. Når man giver alle der taster ordrer den fulde salgsrolle, har man i praksis givet det halve hus adgang til at rette priser.
Selve strukturen holder jeg i tre lag, og jeg har efterhånden svært ved at se en installation hvor det ikke passer.
Nederst en basisgruppe alle er medlem af, med login, læseadgang til det fælles og godkendelsesindbakken. Så en funktionsgruppe pr. jobfunktion, som dækker det daglige arbejde, men hvor der bevidst ikke ligger bogføring af det farlige og ikke ligger opsætning. Og øverst nogle små tillægsgrupper til det som kun få skal have: bogføring af kladder, frigivelse af betalingsfiler, ændring af bankoplysninger på kreditorer, vedligeholdelse af salgspriser. De sidste er de eneste som kræver en egentlig disciplin, og heldigvis er de små nok til at man kan gennemgå dem en gang i kvartalet uden at det bliver et projekt.
Fordelen ved at splitte det op i lag frem for at bygge fem tunge afdelingsgrupper er, at “least privilege” holder op med at være en ambition man nævner i et oplæg, og bliver noget man kan se. Skal Mette kunne frigive betalinger i tre måneder mens der er sygdom i bogholderiet, får hun tillægsgruppen i tre måneder. Hun får ikke Jens’ rettigheder, og de bliver ikke hængende i tre år.
Hvad det koster
Jeg vil ikke lade som om det er gratis, for det er det ikke, og jeg har set nok af de her opsætninger til at kende de tre steder hvor det går galt.
Det første er at rodet flytter, hvis der ikke er nogen som ejer grupperne. En security group uden ejer bliver til en gruppe hvor folk bliver lagt ind og aldrig taget ud, og så har man præcis den samme aflejring som før, bare i Entra i stedet for på brugerkortet. Jeg synes gruppens beskrivelsesfelt er det billigste værktøj vi har til det: skriv hvad rollen er, og skriv hvem der godkender nye medlemmer. Det tager tredive sekunder og bliver læst om to år.
Det andet er begrebsforvirringen, som Microsoft desværre har inviteret til. Der er to ting som hedder security group. Der er den Entra-gruppe man sætter på miljøet i admin center, som styrer hvem der overhovedet kan logge på, og der er siden Security Groups inde i miljøet, som styrer hvad man må når man er kommet ind (spørg mig ikke hvorfor de skulle hedde det samme). De to ting løser hver sit problem, og de bør sættes op samtidigt, blandt andet fordi et sandkassemiljø uden en gruppe på står åbent for alle med en licens i tenanten.
Det tredje er licensen, som stadig er loftet over alt det andet. En Team Member med SUPER er stadig en Team Member. Det er en pointe man kan bruge lang tid på at forklare, men den er nem at vise: åbn Effective Permissions på brugeren, og se på de værdier som står i kantede parenteser. De er ikke effektive, fordi entitlementet trumfer dem. Jeg har brugt den skærm som argument flere gange end jeg har brugt den til fejlsøgning.
Og så er der den ting som værktøjet ikke løser. Grupperne fjerner ikke behovet for at nogen beslutter hvad en indkøber egentlig må. De gør bare beslutningen synlig, og det er også derfor arbejdet ofte føles sværere end det plejede. Det er ikke fordi opsætningen er svær (den tager en formiddag), men fordi der ligger nogle spørgsmål i den som ingen har haft lyst til at tage stilling til. Mit gæt er, at det er derfor “kopiér fra Jens” har været så sejlivet en praksis.
Og hvad med Jens
Jeg vil gerne give kopieringen kredit, for den var den hurtigste ting som virkede. Den fik en ny kollega i gang på tyve minutter en travl mandag, den krævede ingen møder, og jeg har selv skrevet den sætning i en Teams-tråd. Mindst to gange, og jeg husker tydeligt hvor rimeligt det føltes begge gange. Der er også noget rigtigt i den, for Jens ved faktisk hvad man skal kunne for at passe et lager.
Det den ikke kan, er at holde. En kopi af en kopi af en kopi ender med at være en beskrivelse af elleve års undtagelser og ingens jobfunktion, og på et tidspunkt kommer der en revisor, en betaling til den forkerte konto eller bare en ny økonomichef, som gerne vil vide hvem der må hvad.
Det gode ved security groups er ikke at de sparer tid, selvom de gør det. Det vigtigste er, at spørgsmålet på mandag ikke længere er hvem den nye ligner mest, men hvilken rolle hun er ansat til. Så kan Jens beholde sit SUPER indtil han går på pension.
Selvom det nok stadig er en god idé at fjerne det.
Kilder
- Microsoft Learn, om overgangen fra user groups til security groups. ↩︎
