Politikker, godkendelser og ledelse

Alle styrede handlinger følger samme forløb, uanset om de flytter midler eller ændrer organisationens konfiguration:

1 – Initiering. Et medlem, hvis workflowprofil indeholder Initier (eller Udfør) på workflowet, starter en anmodning. For udbetalinger og overførsler skal vedkommende også have den tilsvarende tilladelse til at flytte midler på de involverede konti.

2 – Øjeblikkelig gennemførelseskontrol. Hvis medlemmet har Udfør, og workflowets indstilling »Kræv altid godkendelse« er SLÅET FRA, gennemføres anmodningen med det samme. Færdig. Én undtagelse: en anmodning, der ændrer en låst politik, afventer altid godkendelse, uanset hvilke rettigheder anmoderen har – se »Låsning af politikker« nedenfor.

3 – Godkendelseskø. Ellers afventer anmodningen gennemgang. Medlemmer med Godkend på det pågældende workflow kan se anmodningen i deres kø.

4 – Afgørelse. Når det påkrævede antal uafhængige godkendelser er nået, gennemføres anmodningen og træder i kraft. En enkelt godkender kan i stedet afvise den, hvilket afslutter anmodningen uden virkning.

Gennemførte anmodninger registreres som sikkerhedshændelser og knyttes til anmodningen og dens godkendelsesspor.

Et medlem kan ikke godkende sin egen anmodning. Systemet håndhæver dette på alle arbejdsgange, og ingen rettighed, profil eller politikkonfiguration kan tilsidesætte det.

Den eneste måde, et enkelt medlem kan gennemføre en styret handling alene, er med Execute – og kun når arbejdsgangens politik tillader øjeblikkelig gennemførelse.

Hver arbejdsgangs politik har to indstillinger:

Samspillet mellem Execute og „Kræv altid godkendelse":

Execute fjernes aldrig af en politik – den forbliver på profilen og vises tydeligt som inaktiv, mens "Kræv altid godkendelse" er TIL, og fungerer igen, hvis indstillingen senere sættes til FRA.

1. Gå til Politikker og vælg arbejdsgangen (f.eks. Udbetalingsanmodning).
2. Angiv det påkrævede antal godkendelser.
3. Vælg, om Kræv altid godkendelse skal være TIL eller FRA.
4. Gennemgå, hvem der aktuelt har hvert adgangsniveau i denne arbejdsgang – politikeditoren viser teamets niveauer ved siden af indstillingerne, så du kan kontrollere, at konfigurationen kan opfyldes, inden du gemmer.
5. Bekræft.

Politikændringer er selv styrede handlinger under arbejdsgangen Administrer politikker. Kræver den pågældende arbejdsgang godkendelse, venter din ændring i køen som enhver anden anmodning.

Hver politik har sin egen ændringshistorik: alle opdateringer, låsninger og oplåsninger er anført der med den tilhørende godkendelsesanmodning, så du altid kan se, hvad der blev ændret, hvem der anmodede om det, og hvem der godkendte det. Gennemførte ændringer registreres ligeledes som sikkerhedshændelser.

Låsning er det afgørende trin i ledelse. Det kræver uafhængig godkendelse af alle fremtidige ændringer af workflowets politik – herunder ændring af antallet af godkendelser, ændring af "Kræv altid godkendelse" eller oplåsning.

Alle politikændringer behandles som en Administrer politikker-anmodning, uanset om målpolitikken er låst eller ej – låsningen ændrer ikke, hvor en ændring sendes hen, kun hvordan den gennemføres:

• En ændring af en ulåst politik følger den normale anmodningsproces. Et medlem med Execute-rettighed på Administrer politikker gennemfører ændringen øjeblikkeligt, så længe workflowets indstilling "Kræv altid godkendelse" er slået FRA.
• En ændring af en låst politik – antallet af godkendelser, indstillingen "Kræv altid godkendelse" eller oplåsning – afventer altid gennemgang af medlemmer med Approve-rettighed på Administrer politikker. Låsningen tilsidesætter Execute for den pågældende politik og gælder ens for alle: Ejerens ændringer gennemgår den samme proces som andres.

Når en politik er låst, kan ingen enkeltperson alene svække workflowets ledelse. Ændringer forbliver rutineopgaver – ethvert medlem, hvis workflowprofil giver godkendelsesrettighed på Administrer politikker, kan gennemgå og godkende dem – men de kræver altid mindst to personer.

Låsning gælder pr. workflow. Låsning af Udbetalingsanmodning påvirker ikke Overførselsanmodning eller andre workflows – du strammer ét workflow ad gangen i dit eget tempo. Se Udrulning af ledelsesstrukturen for den anbefalede fremgangsmåde.

Lås og oplåsning er også anmodninger

Tre typer anmodninger behandles under workflowet Administrer politikker. Du vil se dem oplistet i godkendelseskøen, i hver politiks ændringshistorik og i sikkerhedshændelser:

Låsning er ikke undtaget fra sine egne regler: en låsningsanmodning følger samme livscyklus som enhver anden anmodning under Administrer politikker. Hvis du har Execute-rettighed på Administrer politikker og indstillingen «Kræv altid godkendelse» er slået FRA, træder låsningen øjeblikkeligt i kraft – ellers afventer den i køen, og politikken forbliver ulåst, indtil anmodningen er godkendt.

Sådan gennemføres en politikændring

Samlet set er resultatet af enhver anmodning under Administrer politikker følgende:

To måder at styre politikændringer på

De to kontroller supplerer hinanden og er aldrig i konflikt: uanset hvilken der gælder, afventer ændringen godkendelse, og aktiveres begge, ændrer det intet yderligere. Brug låsen til gradvis stramning; brug Manage Policies-indstillingen, når du vil have alle politikændringer gennemgået på én gang.

Låsning af Manage Policies

Manage Policies er et workflow som alle andre: det har sin egen politik, og den politik har sin egen lås. Låsning af Manage Policies er det endelige skridt i en ledelsesudrulning. Når Manage Policies-politikken er låst, kræver enhver ændring af reglerne i hele organisationen – herunder oplåsning af enhver politik og oplåsning af Manage Policies selv – uafhængig godkendelse. Fra det tidspunkt kan ingen enkelt person svække ledelseskontrollen via produktet igen.

Det er også derfor, du bør bekræfte oplåsningsvejen, inden du låser – som beskrevet under »Sikkerhedsforanstaltninger« nedenfor. Intet i produktet forhindrer dig i at låse en politik fast i en tilstand, ingen kan ændre. Se Udrulning af ledelse for, hvornår du bør tage dette skridt.

Bekræft, at oplåsning stadig er mulig, inden du låser. Oplåsning er en Manage Policies-anmodning mod en låst politik, så Execute kan ikke omgå den. Du skal bruge et Medlem, der kan starte en Manage Policies-anmodning, samt så mange andre Medlemmer med Approve på Manage Policies, som workflowet kræver – alle verificerede og aktive. Systemet kontrollerer ikke dette for dig, og en låst politik uden nogen vej til en godkendt ændring kræver Krakens Support for at blive gendannet.

Forebyggelse af udelukkelse. En ændring afvises, hvis den ville efterlade et workflow uden nogen, der kan gennemføre de anmodninger, der er startet på det. Fordi Medlemmer ikke kan godkende deres egne anmodninger, sker dette, så snart det påkrævede antal overstiger, hvad en enkelt initiativtager kan nå for sine egne anmodninger. Kontrollen kører på begge sider: når du redigerer en politik, og når du ændrer et Medlems Workflow Profile eller en Account Role.

Advarsel om deaktivering. Bekræft godkenderdækningen, inden du deaktiverer et Medlem med Approve. Deaktivering gennemføres, selvom det bringer et workflow under det påkrævede antal godkendelser, og afventende anmodninger holdes til den tærskel, der gjaldt, da de blev oprettet.

Når politikkerne giver mening, gennemgår Udrulning af ledelse dem sikkert trin for trin: konfigurer, valider og lås – ét workflow ad gangen, med gennemarbejdede eksempler.

»Kræv altid godkendelse« er slået TIL for det pågældende workflow. Execute er inaktiv, mens indstillingen er slået TIL; alle anmodninger stilles i kø til uafhængig godkendelse. Slå indstillingen FRA under Politikker for at gendanne øjeblikkelig gennemførelse – bemærk, at dette er en Manage Policies-handling, som muligvis selv kræver godkendelse.

Hvis den pågældende anmodning er en politikændring, skal du også tjekke målpolitikken: ændringer af en låst politik venter altid på godkendelse, uanset Execute. Det er låsen, der fungerer som tilsigtet.

Låsning er i sig selv en Manage Policies-anmodning. Hvis »Kræv altid godkendelse« er slået TIL for Manage Policies, eller din Workflow Profile ikke har Execute på det, venter låsen på uafhængig godkendelse ligesom enhver anden anmodning. Politikken forbliver ulåst, indtil låseanmodningen er godkendt – du finder den i godkendelseskøen og i politikkens ændringshistorik, når den er gennemført.

Tæl de aktive medlemmer med Approve på det pågældende workflow – dig selv undtaget. Kun medlemmer, der har accepteret deres invitation og gennemført verifikation, tæller med til godkendelser: et inviteret medlem tæller ikke, før begge dele er på plads, selvom vedkommende vises på din teamliste. Hvis en godkender blev deaktiveret efter anmodningen blev oprettet, kan de resterende godkendere muligvis ikke længere nå det krævede antal – en afventende anmodning fastholdes ved den tærskel, der gjaldt på oprettelsestidspunktet, selvom politikken siden er ændret. Genaktiver medlemmet, eller tildel Approve til et andet aktivt medlem for at fjerne blokeringen.

Tjek din Workflow Profile: låsning kræver Initiate eller Execute på Manage Policies-workflowet. Hvis låseanmodningen blev oprettet, men intet ændrede sig, venter den på godkendelse i stedet for at blive afvist – se punktet ovenfor.

Systemet afviser ikke en låseanmodning på grund af manglende uafhængig godkender, så bekræft selv oplåsningsvejen, inden du låser: du skal bruge et medlem, der kan starte en Manage Policies-anmodning, plus så mange andre medlemmer med Approve på Manage Policies, som det pågældende workflow kræver.

Det krævede antal godkendelser overstiger, hvad et medlem, der starter anmodninger, kan opnå, da ingen kan godkende egne anmodninger. Politikeditoren angiver årsagen: et eller flere medlemmer har både Initiate og Approve, og hvert af dem mangler derfor én godkender i forhold til det samlede antal. Reducer det krævede antal godkendelser, eller tildel Approve til et andet medlem, der ikke starter anmodninger på dette workflow.