Erfahren Sie, wie Sie einen delegierten Genehmigungs-Workflow mit klarer Zuständigkeit, OOO-Regeln und Eskalationspfaden entwerfen, der bei Teamwechseln wartbar bleibt.
„Im Auftrag genehmigen“ klingt in der Theorie einfach: Wenn die eigentliche verantwortliche Person nicht erreichbar ist, kann jemand anderes zustimmen, damit die Arbeit weiterläuft. In der Praxis wird daraus oft ein Graubereich, in dem Tempo und Verantwortlichkeit in verschiedene Richtungen ziehen.
Abwesenheit (OOO) ist der übliche Auslöser. Eine Anfrage landet in der Warteschlange einer Person, diese Person ist weg, und das System tut entweder nichts oder leitet an die falsche Stelle weiter. Ohne klare Regeln beginnen Leute, E-Mails weiterzuleiten, Manager im Chat anzupingen oder Annahmen zu treffen. Bis eine Genehmigung erfolgt, ist oft niemand so richtig sicher, wer die Entscheidung besaß.
Das sind typische Symptome, wenn ein delegierter Genehmigungs-Workflow nicht klar definiert ist:
Das Problem ist nicht die Delegation selbst, sondern die unklare Verantwortung. Wenn Menschen nicht wissen, wer verantwortlich ist, verlangsamen sie sich aus Selbstschutz oder hetzen und hoffen, es sei in Ordnung.
Das wirkliche Ziel ist, Entscheidungen voranzubringen, ohne die Zuständigkeit zu verlieren. Das heißt: Jede Genehmigung sollte weiterhin einen klaren Owner haben, auch wenn jemand anderes während seiner Abwesenheit den Button klickt. Und wenn der Stellvertreter nicht die richtige Person ist, sollte die Anfrage auf vorhersehbare Weise eskalieren, statt in eine Schnitzeljagd zu münden.
Wenn Sie das in einem Tool wie AppMaster aufbauen, behandeln Sie Delegation und OOO als erstklassige Regeln, nicht als Ausnahme, damit der Workflow verständlich bleibt, auch wenn Teams und Organigramme sich verändern.
Ein delegierter Genehmigungs-Workflow bricht zusammen, wenn nicht klar ist, wer verantwortlich ist, wer temporär handelt und wer eingeschaltet wird, wenn es stockt. Beginnen Sie damit, die Rollen in klarem, einheitlichem Wortlaut zu benennen und dieselben Begriffe überall zu verwenden: in der Richtlinie, in Formularen und im Workflow-Tool.
Eine einfache Einteilung, die die meisten Teams abdeckt:
„Owner/Verantwortlicher“ ist das Schlüsselwort. Verantwortung bedeutet Haftung, nicht nur auf "Genehmigen" klicken. Der Owner definiert, was „ausreichend“ ist, und ist für das Ergebnis verantwortlich, auch wenn ein Stellvertreter den Button drückt.
„Stellvertreter“ sollte als temporäre Erlaubnis behandelt werden, nicht als zweiter Owner. Machen Sie die Grenzen sichtbar: welche Arten von Anfragen, bis zu welchem Betrag, für welches Team und wie lange. Wenn Sie das in AppMaster abbilden, hilft es, Owner und Stellvertreter als eigene Felder zu speichern und zu protokollieren, wer tatsächlich gehandelt hat, damit die Auditspur klar bleibt.
„Eskalation“ beantwortet die Frage: Wer greift ein und wann? Formulieren Sie sie als Auslöser, nicht als vage Idee: zum Beispiel „wenn nach 2 Arbeitstagen keine Aktion, an die Führungskraft des Owners weiterleiten“ oder „wenn der Stellvertreter ablehnt, an den Owner zurückleiten, wenn er zurück ist, es sei denn, es ist dringend.“ So wird Delegation nicht zur stillen Genehmigung oder endlosem Warten.
Ein delegierter Genehmigungs-Workflow bleibt nur fair, wenn allen klar ist, was ein Stellvertreter darf und was nicht. Ohne klare Grenzen entstehen zwei schlechte Ergebnisse: risikoreiche Anfragen werden durchgewunken und einfache Anfragen bleiben liegen, weil niemand sie anfassen will.
Beginnen Sie damit, Genehmigungen in „routine“ und „hochriskant“ zu unterteilen. Routine-Items sind wiederholbar, geringfügig und leicht zu prüfen (zum Beispiel standardmäßige Reisebuchungen innerhalb der Richtlinie, kleine Software-Verlängerungen oder vorab genehmigte Rechnungen). Hochrisiko-Items ändern Verpflichtungen oder Exponierung (neue Lieferanten, Vertragskonditionen, Zugang zu sensiblen Daten, Ausnahmen von Richtlinien oder alles, was eine rechtliche oder sicherheitsrelevante Prüfung auslöst). Hochrisiko-Fälle dürfen nie im Auftrag genehmigt werden, ohne eine explizit benannte Backup-Person oder eine höhere Freigabe.
Formulieren Sie die Grenzen so, dass man sie in Sekunden anwenden kann:
Zeitliche Grenzen sind wichtiger, als viele erwarten. Eine Regel wie „während des Urlaubs“ ist vage, wenn Teams über mehrere Zeitzonen verteilt sind. Verwenden Sie genaue Start- und Endzeiten und legen Sie fest, ob „Enddatum“ das Ende des Arbeitstages oder Mitternacht bedeutet.
Machen Sie Prüfanforderungen unverhandelbar. Jede Entscheidung sollte zwei Namen aufzeichnen: wer auf "Genehmigen" geklickt hat und in wessen Namen. In AppMaster bedeutet das typischerweise, beide Identitäten und die damals aktive Delegationsregel zu speichern, damit sich später Fragen ohne Rätsel lösen lassen.
OOO-Regeln scheitern, wenn sie anders funktionieren als erwartet. Ziel ist einfach: Jeder soll wissen, wer handeln kann, wann er handeln kann und was passiert, wenn niemand verfügbar ist.
Beginnen Sie damit, festzulegen, woher der OOO-Status kommt, und machen Sie das konsistent. Ein manueller Umschalter ist am zuverlässigsten (die Person besitzt ihn), aber leicht zu vergessen. Kalenderbasierter Status ist praktisch, aber Besprechungen bedeuten nicht immer „nicht verfügbar“. Einen zeitplan vom Manager zu setzen funktioniert gut für geplante Abwesenheit, kann aber bei plötzlichen Krankheitsfällen hinter der Realität zurückbleiben.
Wählen Sie als Nächstes ein Standardverhalten und halten Sie sich im gesamten Workflow daran. Die meisten Teams entscheiden sich für eines der folgenden:
Was auch immer Sie wählen: Verhindern Sie „Schatten-Genehmigungen“. Wenn jemand im Namen des Owners genehmigt, benachrichtigen Sie sowohl den Owner als auch den Antragsteller. Die Nachricht sollte enthalten: wer genehmigt hat, warum (OOO-Regel) und was genehmigt wurde. So bleibt die Verantwortlichkeit klar und unangenehme Überraschungen nach der Rückkehr des Owners bleiben aus.
Teilverfügbarkeit ist der Punkt, an dem Workflows meist unübersichtlich werden. Definieren Sie sie als Regeln, nicht als Gefühl. Zum Beispiel:
Ein kleines, realistisches Beispiel: Wenn ein Manager im Urlaub ist, aber als „nur morgens“ markiert ist, kann eine 200‑€ Software-Erneuerung um 9:00 an ihn geleitet werden, aber ein 5.000‑€ Einkauf geht an den Stellvertreter und informiert den Manager.
Wenn Sie das in AppMaster bauen, halten Sie die Regelmenge sichtbar und editierbar an einem Ort (nicht über mehrere Schritte verstreut), damit das Verhalten vorhersehbar bleibt, wenn Teams und Richtlinien sich ändern.
Ein wartbarer Approve-on-behalf-Flow bleibt für Antragsteller einfach und für Genehmiger präzise. Ziel ist, die Frage „Wer besitzt diese Entscheidung gerade?“ in jedem Schritt offensichtlich zu machen, auch Monate später.
Ein praktischer delegierter Genehmigungs-Workflow, den Sie in fast jedem System nachbilden können:
Wenn Sie das in AppMaster bauen, halten Sie das Datenmodell klein (Request, Approval, DelegateRule) und legen Sie die Routing-Logik in einen einzigen Business Process, damit Änderungen an einer Stelle stattfinden können, wenn Teams oder Richtlinien sich weiterentwickeln.
Ein Eskalationspfad ist Ihr Sicherheitsnetz. Ohne ihn bleiben Anfragen in der Schwebe, Leute jagen sich im Chat, und das Geschäft macht Ausnahmen, die dann zur "realen" Vorgehensweise werden.
Beginnen Sie damit, zu entscheiden, was niemals automatisch genehmigt werden sollte. Auto-Approve kann für niedriges Risiko und geringe Kosten in Ordnung sein (wie eine standardisierte Software-Verlängerung unter einem kleinen Schwellenwert). Für alles, was Budget, Vertragsbedingungen, Sicherheitslage oder Compliance ändert, sollte es manuell bleiben. Wenn später jemand verantwortlich sein muss, sollte ein Mensch die Genehmigung klicken.
Delegate: eine Person oder ein Pool
Ein einzelner Stellvertreter ist einfach und schnell, aber fragil. Ein Stellvertreter-Pool (zwei oder drei geschulte Genehmiger) ist sicherer, besonders für Teams mit Reisen, Schichtbetrieb oder häufigem PTO.
Wenn Sie einen Pool verwenden, legen Sie eine klare Tiebreak-Regel fest, damit es nicht heißt „jeder dachte, jemand anderes würde es tun“:
Ein praktische Eskalationsleiter
Für einen delegierten Genehmigungs-Workflow hält eine einfache Leiter die Zuständigkeit klar:
Definieren Sie Zeitspannen, damit es vorhersehbar weitergeht, z. B.: Stellvertreter hat 8 Werksstunden, Manager hat 1 Arbeitstag, dann eskaliert es erneut.
Planen Sie für den schlimmsten Fall: Owner und Stellvertreter sind beide nicht erreichbar. Verlassen Sie sich nicht auf „irgendjemand wird es bemerken.“ Fügen Sie eine Regel hinzu, die Verfügbarkeit prüft und dann direkt an den Manager (oder den Pool) springt. In Tools wie AppMaster lässt sich das leicht als Status-Timer plus "OOO-Check" im Business Process modellieren, mit protokollierter Übergabe.
Machen Sie die Eskalation sichtbar. Der Antragsteller sollte immer sehen, wer die Genehmigung gerade besitzt und wann sie als Nächstes eskaliert. Das verhindert die meisten Nachfragen.
Ein Support-Team braucht für einen neuen Mitarbeiter ein Laptop. Der Antragsteller stellt eine Kaufanfrage über 1.200 €; normalerweise geht das an seine Managerin Priya. Priya ist eine Woche im Urlaub und als OOO markiert.
Priya hat einen benannten Stellvertreter, Marcus, mit der klaren Regel: Er kann Käufe bis 1.000 € in ihrem Namen genehmigen. Alles darüber muss an den nächsten Entscheider, den Abteilungsleiter, gehen, Marcus bleibt aber informiert. Diese einzelne Grenze hält den Prozess vorhersehbar und leicht erklärbar.
So bewegt sich die Anfrage, wobei alle dieselbe Geschichte in den Benachrichtigungen sehen:
Die entscheidende Sache ist die Formulierung und Zuständigkeit. Der Antragsteller fragt nie, wer die Anfrage hält. Der Stellvertreter gibt sich nicht als Manager aus, die Aktion ist klar als „im Auftrag von“ gekennzeichnet, und der eskalierte Entscheider sieht sowohl die ursprüngliche Anfrage als auch die Entscheidung des Stellvertreters.
Wenn Sie das in AppMaster bauen, behandeln Sie die Regeln als Daten (wer ist OOO, wer ist Stellvertreter, wie hoch ist das Limit, wohin eskaliert es nach 24 Stunden). So können Sie die Richtlinie später anpassen, ohne den gesamten Workflow umzuschreiben.
Der schnellste Weg, einen delegierten Genehmigungs-Workflow zu zerstören, ist, Delegation als schnelle Abkürzung statt als kontrollierte, zeitlich begrenzte Regel zu behandeln. Die meisten Probleme tauchen Monate später auf, wenn niemand mehr weiß, warum ein Stellvertreter noch Befugnisse hat.
Ein großes Risiko sind Delegationen ohne Ablaufdatum. Eine temporäre Übergabe wird stillschweigend zur dauerhaften Berechtigung — so werden „Im-Auftrag“-Genehmigungen zu einem Sicherheits- und Auditproblem.
Ein anderer Fallstrick ist, an die falsche Rolle zu delegieren. Leute wählen jemanden, der verfügbar ist, nicht jemanden, der Kontext oder Autorität hat. Das führt zu Rubber-Stamp-Genehmigungen oder zu ständigem Hin- und Herschicken.
Die schlimmsten Fehler:
Auditfähigkeit wird oft übersehen. Wenn eine Anfrage einfach „Genehmigt von Sam“ anzeigt, geht die Geschichte verloren: Wer war Owner, wer hat gehandelt und warum war das zulässig? Selbst eine einfache Formulierung wie „Sam (Stellvertreter für Priya)" verhindert spätere Streitigkeiten.
Eskalationsschleifen sind tückisch, weil sie wie ein funktionierender Prozess aussehen, bis es dringend wird. Ein übliches Muster: Owner delegiert an Manager, aber die Eskalation des Managers zeigt zurück auf das Team des Owners. Die Anfrage kreist, bis jemand manuell eingreift.
Wenn Sie das in AppMaster bauen, halten Sie die Regeln lesbar: zeitlich begrenzte Delegationen, eine einzige Quelle der Wahrheit für Zuständigkeiten und ein verpflichtendes "im Auftrag von"-Feld im Genehmigungsdatensatz. Änderungen sollten möglich sein, ohne ein Netz aus Ausnahmen umzuschreiben.
Bevor Sie einen delegierten Genehmigungs-Workflow unternehmensweit einführen, prüfen Sie die Grundlagen. Die meisten späteren Probleme stammen von fehlender Zuständigkeit, vagen Limits und ungetesteten Eskalationen.
Nutzen Sie diese Checkliste und stellen Sie sicher, dass jede Frage schriftlich beantwortet ist, nicht mit „das weiß ja jeder".
Nach dem Abhaken führen Sie einen kurzen Pilot mit einem Team für eine Woche durch. Stellen Sie zwei Fragen: „War etwas überraschend?“ und „Könnte jemand in einem Satz erklären, wer diese Genehmigung besitzt?“ Wenn eine Antwort nein ist, korrigieren Sie die Regeln, bevor Sie weiter ausrollen.
Wenn Sie das in AppMaster bauen, machen Sie diese Felder und Zustände verpflichtend, damit der Prozess konsistent bleibt, auch wenn Menschen und Organigramme sich ändern.
Ein delegierter Genehmigungs-Workflow bleibt nur gesund, wenn Menschen zwei Fragen schnell beantworten können: „Welche Regel gilt?“ und „Wer besitzt diese Regel?“ Wenn eine Antwort unklar ist, entstehen Einzelfälle und der Prozess wird unzuverlässig.
Bewahren Sie Regeln an einem Ort. Nutzen Sie ein zentrales Register von Anfragearten (z. B. „Einkauf unter 5.000 €" oder „Zugriff auf Kundendaten") und verwenden Sie konsistente Bezeichnungen in Formularen, Benachrichtigungen und Berichten. Konsistente Namen erleichtern Audits, das Onboarding neuer Manager und verhindern doppelte Pfade, die dasselbe tun.
Machen Sie Delegations-Reviews zur Routine, nicht zur Notfallmaßnahme. Eine monatliche Prüfung fängt veraltete Zuordnungen durch Rollenwechsel, Versetzungen oder ausgetretene Personen. Führen Sie außerdem eine Ad-hoc-Überprüfung bei Reorganisationen, Änderungen der Genehmigungslimits oder neuen Richtlinien durch.
Einige leichte Gewohnheiten verhindern 90 % des langfristigen Drift:
Sammeln Sie gerade genug Daten, um Probleme früh zu erkennen. Sie brauchen keine komplexe Analytik, aber Signale, dass etwas schiefläuft:
Planen Sie Wachstum vor. Neue Teams werden eigene Limits und Sonderfälle wollen; gestalten Sie Regeln so, dass neue Anfragearten hinzugefügt werden können, ohne alles neu zu schreiben. In einem No-Code-Tool wie AppMaster behandeln Sie Genehmigungsregeln als versioniertes Asset: ändern Sie sie an einer Stelle, testen Sie mit einer kleinen Nutzergruppe und veröffentlichen Sie dann die aktualisierte Logik.
Wählen Sie einen Genehmigungs-Workflow als Start, nicht fünf. Nehmen Sie etwas Häufiges, Gering-Risiko- und Gut-Messbares, z. B. Einkaufsanfragen unter einem definierten Betrag. Verwenden Sie eine Eskalationsleiter (z. B. Backup-Genehmiger, dann Manager, dann Finanzen), damit Sie sehen, wo der Prozess bricht, bevor Sie ihn skalieren.
Entscheiden Sie, welche Daten Sie am ersten Tag brauchen, denn das beeinflusst Routing und Auditspur später. Viele Teams bedauern, nicht das „Warum" hinter einer Entscheidung oder die genaue Übergabe in der Abwesenheitsregel gespeichert zu haben.
Ein einfaches Pilot-Datenset umfasst üblicherweise:
Wenn Sie das ohne viel Programmierung aufbauen wollen, können Sie Genehmigungen, OOO-Regeln und Eskalationen in AppMaster modellieren: Data Designer zum Definieren von Genehmigern, Limits und OOO-Fenstern und Business Process Editor zum Weiterleiten von Anfragen, Starten von Timern und Protokollieren jeder Entscheidung. Halten Sie die erste Version strikt und lesbar, auch wenn das weniger Spezialfälle bedeutet.
Schreiben Sie die Regeln vor dem Pilot in einfacher Sprache nieder. Das vermeidet „kommt drauf an"-Entscheidungen, die stillschweigend zu Ausnahmen werden.
Führen Sie einen zweiwöchigen Pilot mit einem kleinen Team und einem klaren Owner durch. Während des Pilots erfassen Sie nur das, was zählt:
Nach dem Pilot passen Sie Rollen, Limits und Timer an und erweitern dann auf den nächsten Workflow. Wenn Sie einem neuen Manager die Abläufe nicht in zwei Minuten erklären können, vereinfachen Sie sie, bevor Sie weiter ausrollen.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
