Hvad beskytter hver godkendelse?

Et team beskrev i en optagelse et forsøg, der ikke kunne fortsætte, før fjorten personer var blevet spurgt. Forsinkelsen opstod, før nogen havde sagt nej. Arbejdet stod i kø til tilladelser, der endnu ikke var indhentet.

Kildeklippet beskriver en regel, der begrænsede vetoret, men bevarede ledelseskontrol og juridiske eller privatlivsmæssige kontroller. Det er en beretning om én organisation, ikke bevis for, at alle virksomheder bør kopiere dens struktur. For et integrationsteam er det nyttige spørgsmål enklere: Hvad beskytter hver godkendelse?

Tegn den faktiske beslutningsvej

Antag, at et tænkt team vil føje en ny kundeattribut til en synkronisering fra butik til e-mailplatform. Produktteamet vurderer behovet. Udviklingsteamet vurderer mappingen. Sikkerhedsteamet vurderer dataomfanget. Marketing vurderer målgruppen. En administrator godkender ændringen i målsystemet.

Fem kontrolpunkter kan være berettigede. Fem kontrolpunkter kan også rumme tre kopier af samme spørgsmål. Antallet alene kan ikke fortælle det.

Skriv ved hvert punkt, hvilken beslutning det har ansvar for. »Indeholder feltet data, som målsystemet må modtage?« er et særskilt spørgsmål om sikkerhed og privatliv. »Vil målgruppen indeholde de rigtige kunder?« er et marketingspørgsmål. »Passer mappingen til målsystemets type?« kan ofte kontrolleres i kode. Et møde, der blot spørger, om et andet møde godkendte det, beskytter ikke mod noget nyt.

Guiden til at integrere virksomhedsværktøjer spørger, hvilket system der bestemmer over hvert objekt, og hvilken hændelse der skal udløse en overførsel. Det er beslutningsrettigheder. Placer dem tidligt i forløbet, hvor senere godkendere kan bruge dem.

Et kort over køen bør vise overdragelser, ikke kun navnene på godkenderne. En forespørgsel kan vente to dage på, at nogen finder den ansvarlige for målsystemet, og derefter bruge få minutter på selve gennemgangen. Hvis den ansvarlige kan findes ud fra konto og datatype, så send forespørgslen direkte. Hvis beslutningen afhænger af sammenhængen, så medtag den i forespørgslen, så godkenderen ikke begynder endnu en spørgerunde. Den kortere vej kommer både fra at fjerne søgning og omarbejde og fra at fjerne gentagne vetoer.

Placer kontrollen, hvor konsekvenserne begynder

Den rimelige indvending mod færre godkendelser er stærk: »Én forkert synkronisering kan flytte private kundedata.« Ja. At fjerne kontrollen ved den grænse ville være uforsvarligt. Men en godkendelse af en lille, isoleret forhåndsvisning af en mapping er ikke det samme som tilladelse til at aktivere en bred opdatering i drift.

Adskil den reversible øvelse fra handlingen med reelle konsekvenser. Et udkast kan undersøges uden at ændre et målsystem. En forhåndsvisning kan begrænses til kendte poster. Aktivering påvirker rigtige data og bør kræve den beføjelse, der passer til virkningen. Det giver en kortere vej til læring og en fast kontrol ved handling.

Grænsen skal håndhæves af systemet. Et afsnit, der beder en agent spørge om lov, er ikke et godkendelsespunkt, hvis samme agent alligevel kan kalde opdateringen i drift. Kontrollen skal være knyttet til den præcise handling og konto og efterlade dokumentation for, hvem der godkendte den.

Det betyder ikke, at hver godkender skal komme fra et forskelligt team. Personen med beføjelser over dataene kan være den samme, som forstår kampagnen. Pointen er at matche beføjelser med konsekvensen frem for organisationsdiagrammet.

Hold øje med kontrolpunkter, der flytter sig i stedet for at forsvinde. Hvis et team fjerner en formel godkendelse, men udviklere stadig venter på en uformel besked fra samme gruppe, har forløbet ikke ændret sig. Registrer tidspunktet for første forespørgsel, tidspunktet for et komplet beslutningsgrundlag, beslutningstidspunktet og handlingstidspunktet. Det adskiller forsinkelse på grund af manglende dokumentation fra forsinkelse på grund af beføjelser. Løsningen er forskellig: bedre input til den første, tydeligere ansvar til den anden.

1. Foreslået ændring af synkronisering

2. FORHÅNDSKONTROL

   Kontrollér entydige fakta

   • Felttype og afgrænsning af målsystem
3. AFPRØVNING

   Vis afgrænsede poster

   • Undersøg den resulterende tilstand i målsystemet
4. AKTIVERING

   Godkend konsekvensen

   • Den dataansvarlige tillader virkningen i drift

5. Aktiv regel med en ansvarlig ejer

Mål både ventetid og fundne fejl

Et fristende dashboard viser »godkendelsestiden er reduceret med 60 %«. Uden dokumentation for, hvad de gamle kontrolpunkter fangede, kan det fejre et tab af beskyttelse. Registrer to ting for hvert punkt: ventetiden og den type problem, det opdager. Hvis et kontrolpunkt aldrig finder et problem, så undersøg, om det kan automatiseres eller fjernes. Hvis det fanger en sjælden, men alvorlig tilladelsesfejl, så behold det, og forkort ventetiden.

En tænkt gennemgang kan vise, at tre kontroller alle undersøger felttypen, mens ingen undersøger, om samtykket i kilden gælder kampagnen i målsystemet. Løsningen er ikke blot færre godkendelser. Det er et bedre spørgsmål ved det afgørende kontrolpunkt.

Guiden til Brevo-connectoren viser, hvorfor et felt kan se ud til at være mappet, selv om målsystemet ikke indeholder den tilsigtede værdi. En typekontrol før opdateringen kan håndtere en del af problemet. En person har stadig ansvaret for beslutningen om at bruge den resulterende målgruppe.

Godkendelse har en omkostning. Det har en ikke-godkendt fejl også.

Prøven er, om den næste forespørgsel når frem til en beslutning med tilstrækkelig dokumentation og de rigtige beføjelser. Et kontrolpunkt, der fanger et reelt privatlivsproblem, fortjener sin plads, men bør modtage de nødvendige fakta uden en uges videresendelser. Et punkt, der gentager en typekontrol, bør blive til en test. Gennemgå forløbet igen, når dataomfanget eller målsystemet ændrer sig. Navngiv den risiko, hvert punkt reducerer, og behold kun de punkter, der er ventetiden værd.