Fra 10 til 200 partnere: Hvad bryder først sammen i et partnerprogram?

Partnerprogrammer bryder sjældent sammen ved 10 partnere. Det sker på vej mod 200, én arbejdsvane ad gangen. Her er de syv brudpunkter i den rækkefølge, de typisk opstår, løsningen på hvert af dem og en tjekliste på én side.

Partnerprogrammer bryder sjældent sammen ved 10 partnere. Ved 10 kender koordinatoren alle partnernes direktører ved navn, status klares med et telefonopkald, og årsrapporten tager en eftermiddag. De bryder sammen på vej mod 200, når den samme koordinator begynder hver mandag med en indbakke fuld af statussvar, en ramme, der findes i tre versioner, og en rapport til bestyrelsen, som vil tage uger at udarbejde.

Der sker ikke noget dramatisk. Programmet passerer en række tærskler, og arbejdsvaner, der fungerede med 10 partnere, holder op med at virke én efter én. Her får du en guide til at skalere et partnerprogram uden dette langsomme sammenbrud: de syv brudpunkter i den rækkefølge, de typisk opstår, hvorfor hvert af dem opstår ved netop den størrelse, og hvordan det løses – først med arbejdsgange og derefter med værktøjer. Dertil en tjekliste på én side til dit team.

Hvorfor partnerprogrammer bryder sammen i etaper: Koordinatoren bliver flaskehalsen

Før jeg begyndte at arbejde med digital transformation, underviste jeg i operationsanalyse på Universitetet i Porto: matematikken bag køer, flaskehalse og kapacitet. Set gennem den linse giver etaperne mening.

I de fleste programmer går næsten alle henvendelser gennem én eller to personer: koordinatoren, der besvarer spørgsmål, kontrollerer dokumenter, indhenter status og samler rapporter. I køteoriens termer er koordinatoren betjeningsenheden, og hver henvendelse er en ankomst.

Littles lov siger, at det gennemsnitlige antal enheder i et system er lig med ankomsthastigheden gange den gennemsnitlige tid, hver enhed tilbringer der [1]. Bunken af ubesvarede henvendelser i koordinatorens indbakke skyldes ikke manglende disciplin; den er ankomster gange ventetid.

Et andet resultat er mindre intuitivt. I den enkleste kø med én betjeningsenhed er den gennemsnitlige tid, en henvendelse tilbringer i systemet, lig med dens behandlingstid divideret med én minus betjeningsenhedens udnyttelsesgrad [2]. Ved 50 % udnyttelse tager det dobbelt så lang tid som selve behandlingstiden at få en henvendelse igennem; ved 80 % fem gange så lang tid; ved 95 % tyve gange. Ventetiden vokser ikke lineært med arbejdsbyrden. Den eksploderer, efterhånden som ugen bliver fyldt op.

Et eksempel med antagelser, som du bør erstatte med dine egne: En koordinator har 20 timer om ugen til partnerhenvendelser, og hver partner sender én henvendelse om ugen, som tager 20 minutter at behandle.

  • 10 partnere: lidt over 3 timer om ugen. Koordinatorens udnyttelsesgrad er 17 %, og henvendelserne venter næsten ikke.
  • 50 partnere: næsten 17 timer. Udnyttelsesgraden er 83 %, og den gennemsnitlige henvendelse tager seks gange sin behandlingstid at få igennem.
  • 60 partnere: alle 20 timer. Køen stabiliserer sig aldrig; den bliver ved med at vokse.

Koordinatoren er ikke blevet langsommere; regnestykket har ændret sig. Det samme regnestykke viser rækkefølgen for løsningerne, præcis som på enhver produktionslinje: Reducér først antallet af ankomster (partnerne finder svar uden at spørge), forkort derefter behandlingstiden (alle henvendelser i samme format og på samme sted), og tilføj først derefter flere medarbejdere. Ansættelser alene flytter blot grænsen: Med de samme antagelser rammer to koordinatorer den ved 120 partnere.

De syv brudpunkter i den rækkefølge, de typisk opstår

En trappe fra 10 til 200 partnere med syv brudpunkter: status indhentes via e-mail, rammen findes i flere versioner, onboarding afhænger af én person, dokumentation forsvinder i indbakker, rapportering tager uger, uklare forventninger på ét sprog, adgangsrettigheder og databeskyttelse
En illustration baseret på erfaring, ikke målte data: den typiske rækkefølge af brudpunkter, når et program vokser. Et større team eller enklere henvendelser forskyder hvert trin mod højre.

1. Status indhentes via e-mail (fra omkring 15 partnere)

Symptom. Hver måned sender nogen en e-mail til alle partnere for at spørge, hvor langt de er, rykker dem, der ikke har svaret, og kopierer svarene ind i et regneark. Når det sidste svar kommer, er det første allerede forældet.

Hvorfor det svigter her. En statusrunde er rene ankomster: én udgående besked og ét indgående svar pr. partner plus påmindelserne. Med 15 partnere tager det en eftermiddag. Med 200 partnere og en månedlig runde er det 2.400 henvendelser om året, før den første påmindelse er sendt.

Løsningen. Hold op med at spørge efter status; gør den synlig. Aftal med partnerne, hvad fremskridt betyder i konkret, observerbar form (et nået trin, en udført opgave, et godkendt dokument), så status bliver et biprodukt af arbejdet.

2. Rammen findes i flere versioner (fra omkring 25)

Symptom. Rammen er en to år gammel PDF, en opdateret Word-fil og et dias fra en workshop, som nogen har forbedret. Partnere, der kom med i forskellige år, arbejder hen imod forskellige definitioner af det samme trin.

Hvorfor det svigter her. Med 10 partnere bliver en ændring meddelt på ét møde, og alle hører den. Med 25 spredes ændringer via vedhæftede filer, og hver kopi bliver en selvstændig variant.

Løsningen. Én ansvarlig, én gældende version, en ændringslog og en dato for, hvornår hver ændring træder i kraft.

3. Onboarding afhænger af én person (fra omkring 40)

Symptom. Nye partnere introduceres til programmet af den person, der har udformet det, i én lang samtale. Når personen holder fri, må onboarding vente; når vedkommende stopper, forsvinder programmets hukommelse med dem.

Hvorfor det svigter her. Onboarding er en henvendelse med lang behandlingstid, og programmer optager ofte partnere i hold. Femten nye partnere i samme måned lander i den samme kalender.

Løsningen. Skriv onboardingprocessen ned: en kort velkomstpakke, de første tre skridt, og hvem man skal spørge om hvad. Så kan den første samtale handle om partneren, ikke om programmet.

4. Dokumentation er spredt ud over indbakker (fra omkring 60)

Symptom. Politikker, revisioner, deltagerlister fra kurser og fotos ankommer som vedhæftede filer til den person, partneren kender bedst. Før en revision eller et donorbesøg bruger teamet dage på at lede i indbakker.

Hvorfor det svigter her. Mængden af dokumentation vokser med antallet af partnere gange antallet af krav, og den lander i personlige indbakker, som kollegerne ikke kan se. Husk også belastningen på den anden side: En ICVA-undersøgelse fra 2016 om donorers betingelser for humanitære NGO'er fandt i gennemsnit 36 rapporteringsfrister pr. land om året og vurderinger af partneres kapacitet, som kunne omfatte mere end 100 spørgsmål og op til 91 bilag [3]. Dine partnere bærer en tilsvarende byrde for dig.

Løsningen. Bed kun om hvert stykke dokumentation én gang, med en frist og knyttet til det krav, det dokumenterer. Bed kun om det, nogen faktisk vil læse.

5. Rapportering tager uger (fra omkring 90)

Symptom. Årsrapporten begynder med en e-mail, der beder alle partnere om tal, fortsætter med ugers sammenlægning af filer og slutter med et diagram, som ingen kan spore tilbage til kilden.

Hvorfor det svigter her. Ved denne størrelse er rapportering et samlearbejde: Hvis data ikke blev indsamlet i én struktur i løbet af året, bygger nogen den ved årets slutning – manuelt. Den samme ICVA-undersøgelse beskriver en international NGO, der beregnede, at den kunne spare 11.000 timers økonomisk rapportering, hvis dens ni største donorer blev enige om omkostningsdefinitioner og accepterede den samme økonomiske skabelon [3]. I Grand Bargain-aftalen fra 2016 forpligtede donorer og hjælpeorganisationer sig til at reducere dobbeltarbejde og administrationsomkostninger og til at forenkle rapportering: mindre omfang, fælles terminologi, grundlæggende krav og en fælles rapportstruktur [4].

Løsningen. Vælg en håndfuld KPI'er, før året begynder, definér dem ens for alle partnere, og indsaml dem, mens arbejdet udføres. Rapporten bliver et dataudtræk, og ugerne kan bruges på at læse den.

6. Partnerne ved ikke, hvad der forventes, eller kan ikke arbejde på deres eget sprog (fra omkring 120)

Symptom. De samme spørgsmål bliver ved med at komme: Hvad skal vi gøre for at nå næste trin, hvilken skabelon skal vi bruge, og hvornår er fristen? Partnere i nogle lande svarer sent eller slet ikke, og det bliver tolket som manglende engagement.

Hvorfor det svigter her. Nu går programmet på tværs af landegrænser, mens forventningerne stadig kun er beskrevet på ét sprog. Forfatterne til en artikel i Humanitarian Exchange fra 2021 bemærkede, at globale vejledninger og tekniske værktøjer normalt kun findes på FN's officielle sprog, og at koordinationsmøder på internationale sprog forværrer problemet [5]. Tavshed er ofte et sprogproblem, ikke et motivationsproblem.

Løsningen. Beskriv hvert trin i et enkelt sprog med observerbare kriterier, og oversæt beskrivelsen sammen med de tilhørende skabeloner. Hvert spørgsmål, siden besvarer, er en henvendelse, der aldrig når køen.

7. Adgangsrettigheder og databeskyttelse (fra omkring 160)

Symptom. Hundredvis af personer har adgang til den delte mappe, ingen er sikre på, hvem der kan se hvilke partneres vurderinger, og databeskyttelsesrådgiveren har spørgsmål, som ingen kan besvare.

Hvorfor det svigter her. Med 10 partnere er én delt mappe praktisk. Med 200 er den en risiko: Partnerregistreringer indeholder personoplysninger og følsomme vurderinger, og adgang, der er tildelt manuelt, bliver sjældent fjernet. Europa-Kommissionens vejledning om databeskyttelse gennem standardindstillinger er, at personoplysninger kun bør være tilgængelige »for et begrænset antal personer, der har et arbejdsbetinget behov« [6].

Løsningen. Definér roller, før det næste hold kommer med: Hvem i dit team må se og ændre hvad, og fastlæg reglen om, at en partner kun ser sine egne data og intet andet. Gennemgå adgangen, når personer tiltræder eller fratræder.

Hvad et værktøj skal kunne ved hvert brudpunkt

Arbejdsgangene kommer først: Et værktøj, der automatiserer en defekt proces, får den blot til at bryde hurtigere sammen. Derefter er dette kravene til et værktøj til partnerstyring i stor skala:

De syv brudpunkter: arbejdsgangen, og hvad et værktøj skal kunne
Brudpunkt Arbejdsgangen først Hvad et værktøj skal kunne
Status indhentes via e-mail Gør status til et biprodukt af arbejdet Lad partnerne registrere fremskridt dér, hvor de arbejder, og vis dig alles placering, uden at du skal spørge
Rammen findes i flere versioner Én ansvarlig, én version, en ændringslog Rum én ramme for alle partnere, som redigeres i fællesskab, og hvor ændringer når alle samtidig
Onboarding afhænger af én person En skriftlig velkomstpakke Vis hver ny partner, fra første login, hvor den står, og hvad næste skridt kræver
Dokumentation forsvinder i indbakker Én anmodning pr. stykke dokumentation Knyt hver upload til det skridt, den dokumenterer, og vis, hvad der mangler på tværs af alle partnere
Rapportering tager uger Nogle få KPI'er, defineret på forhånd Gem KPI'er pr. partner med deres historik, og udarbejd rapporter ud fra disse data
Uklare forventninger, ét sprog Enkle trinbeskrivelser, oversat Vis hver partner dens placering og næste skridt på dens eget sprog
Adgangsrettigheder og databeskyttelse Roller før det næste hold Håndhæv roller, begræns hver partner til egne data, understøt organisationens login, og oplys, hvor filer opbevares

En tjekliste på én side til at vurdere parathed til skalering

Tjeklisten omsætter de syv brudpunkter til 21 udsagn samt koordinatorens kapacitetsberegning med plads til jeres egne tal. Gennemgå den med teamet, før den næste gruppe partnere kommer med, og begynd med det første afsnit, der har to eller flere tomme felter.

Tjeklisten på én side til vurdering af parathed til skalering: tre udsagn for hvert af de syv brudpunkter og et beregningsark til at anslå koordinatorens arbejdsbyrde
Tjeklisten til vurdering af parathed til skalering: syv afsnit, 21 udsagn og beregningsarket til koordinatorens arbejdsbyrde.

Download tjeklisten til vurdering af parathed til skalering (PDF, 1 side). Print den til et teammøde.

Er I allerede forbi det andet brudpunkt? I Advancer.World arbejder alle partnere med én version af jeres program, ser deres egen placering og kravene til næste trin på deres eget sprog og sender dokumentation til det skridt, den hører til. Dit team ser, hvor hver partner står, i stedet for at spørge. Gratis at komme i gang.

Tilmeld dig nu

Partnerstyring i stor skala i Advancer.World

Advancer.World udsprang af digital transformation af programmer hos organisationer som UNICEF og Airbus. Et program er én matrix, der udformes én gang: trin på den ene akse, emner og underemner på den anden, hvor hver celle beskriver, hvordan det pågældende trin ser ud for det pågældende emne. Flere personer i dit team kan udforme den samtidig, og alle partnere arbejder med den samme version.

Programdesign i Advancer.World: et program for medlemsstandarder med fire trin, fra tilslutning til førende, på tværs af ledelse, beskyttelse og programmer
Eksempeldata: en fiktiv føderations program for medlemsstandarder, som programteamet udformer det.

Skridtene mellem cellerne rummer arbejdet: initiativer, spørgeskemaer, anmodninger om dokumentupload og anmodninger om elektronisk underskrift. For hvert program vælger du, hvordan partnerne går videre: ved selvevaluering, automatisk når det foregående skridt er gennemført, eller når dit team bekræfter det. Partnerne inviteres via e-mail og ser deres egen placering og kravene til næste trin på et af 22 sprog, herunder arabisk, urdu, swahili og hausa. De ser aldrig andre partneres data, og partnere og deres medarbejdere betaler aldrig.

Medlemsvisningen i Advancer.World: den samme matrix med medlemsorganisationens nuværende trin markeret i hvert underemne
Det ser en medlemsorganisation (eksempeldata): sin egen placering i hvert underemne og kravene til næste trin.

KPI'er registreres pr. partner, og daglige øjebliksbilleder bevarer historikken, så Excel-rapporterne og de AI-skrevne Word-rapporter med diagrammer bygger på data indsamlet i løbet af året. Din organisation kan logge ind med Microsoft Entra ID, filer opbevares i EU, og på Gold- og Enterprise-abonnementerne kan en AI-assistent læse, hvor dine partnere står, via MCP-serveren. Hvis MCP er nyt for dig, kan du begynde med hvad Model Context Protocol er.

Ofte stillede spørgsmål

Hvor mange partnere kan én koordinator håndtere?

Der findes ikke et fast forholdstal. Gang antallet af partnere med antallet af henvendelser, hver partner sender om ugen, og det antal minutter, hver henvendelse tager, og dividér derefter med de minutter, din koordinator reelt har til partnerarbejde. Det er udnyttelsesgraden. Ved 80 % tager den gennemsnitlige henvendelse allerede fem gange sin behandlingstid at få igennem.

Hvornår bør vi flytte et partnerprogram væk fra regneark og e-mail?

Når to af de første fire brudpunkter viser sig samtidig, eller før den næste gruppe partnere kommer med – alt efter hvad der sker først. Hvis I har brug for hjælp til at overføre eksisterende data, tilbyder Mourinho Solutions hjælp til migrering.

Vil en platform give vores partnere mere arbejde?

Den bør fjerne arbejde. En partner, der besvarer statusmails, sender vedhæftede filer til tre personer og udfylder en ny skabelon for hver finansieringsgiver, udfører allerede arbejdet; et fælles sted ændrer blot, hvor det samles. Bed to eller tre partnere om at prøve det først.

Sådan skalerer du et partnerprogram, uden at det bryder sammen

Du behøver ikke at løse alle syv problemer på én gang. Find det første bristepunkt, dit program allerede har passeret, løs det problem, og regn på koordinatorens arbejdsbelastning, før det næste hold kommer til. Et program, der skalerer godt, har ikke en koordinator, der udfører heltegerninger. Det har en koordinator, hvis uge ikke er fuldt booket. Har du brug for et ekstra sæt øjne på selve programdesignet, tilbyder vi programrådgivning.

Administrer 10 eller 200 partnere i den samme oversigt. Design dit program én gang, inviter dine partnere, og saml dokumentation, KPI'er og historik ét sted i stedet for i din indbakke. Gratis at komme i gang.

Tilmeld dig nu

Referencer

  1. John D. C. Little, "Littles lov set på 50-årsdagen", Operations Research 59(3), s. 536–549, maj–juni 2011, https://doi.org/10.1287/opre.1110.0940 (tilgået oktober 2026).
  2. Richard C. Larson og Amedeo R. Odoni, "Operationsanalyse i byer", Prentice-Hall, 1981, afsnit 4.6.1, "Én operatør, uendeligt antal linjer", https://web.mit.edu/urban_or_book/www/book/chapter4/4.6.1.html (tilgået oktober 2026).
  3. Det Internationale Råd for Frivillige Organisationer (ICVA), "Mindre papir, mere hjælp: Rapportering, vurdering af partnerkapacitet og revision", opdateret september 2016, https://alnap.org/help-library/resources/less-paper-more-aid-reporting-partner-capacity-assessment-and-audit/ (tilgået oktober 2026).
  4. "The Grand Bargain: En fælles forpligtelse til bedre at hjælpe mennesker i nød", Istanbul, 23. maj 2016, https://gblocalisation.ifrc.org/wp-content/uploads/2018/06/grand_bargain_final_22_may_final-2_0.pdf (tilgået oktober 2026).
  5. Mia Marzotto, Kemal Alp Taylan, Fatuma Ibrahim, Marian Ellen Hodgkin, Paul Martin Lukusa Mbwebwa og Charles Abugo, "'Hvordan kan vi bidrage, hvis vi ikke kan deltage?' Lokale og nationale organisationers adgang til humanitære vejledninger", Humanitarian Exchange 79, Humanitarian Practice Network, 25. maj 2021, https://odihpn.org/en/publication/how-can-we-contribute-if-we-cant-participate-the-accessibility-of-humanitarian-guidance-to-local-and-national-organisations/ (tilgået oktober 2026).
  6. Europa-Kommissionen, "Forpligtelser: databeskyttelse gennem design og gennem standardindstillinger", https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations/what-does-data-protection-design-and-default-mean_en (tilgået oktober 2026).

© 2026 Mourinho Solutions. Alle rettigheder forbeholdes.

← Tilbage til bloggen