Betriebshandbuch
Diese Vorlage herunterladen
Erzeugt am 2026-08-31 · Alle Vorlagen herunterladen
Zentrale Betriebsprozesse
Which things have to keep happening every week — and are they written down anywhere?
RCOS-Klauseln 7.3.4, 7.7.2, 7.6.3
- 7.3.4 Kritische Betriebsprozesse MUSS so dokumentiert sein, dass die Kontinuität nicht von implizitem Wissen einzelner Personen abhängt.
- 7.7.2 Kritische Betriebsprozesse DARF NICHT ausschließlich auf individuellem Gedächtnis, gutem Willen oder informeller Weitergabe beruhen.
- 7.6.3 Das Betriebshandbuch MUSS mindestens Folgendes definieren:
Warum kritische Prozesse dokumentieren?
Wenn ein Prozess nur im Kopf einer einzigen Person existiert, hängt die Gemeinschaft davon ab, dass diese Person immer verfügbar ist — für immer. Kritische Prozesse schriftlich festzuhalten, mit benannten Verantwortlichen, verwandelt privates Wissen in ein Gemeinschaftsgut, das Übergaben, Abwesenheiten und Austritte übersteht.
Wie ihr das ausfüllt
Benennt für jeden wiederkehrenden kritischen Prozess (Onboarding, Austritt, Antragsveröffentlichung, Beitragserfassung, Sitzungsrhythmus, Kassenverwaltung, Überprüfung von Plattformzugängen) eine verantwortliche Person und eine kurze Beschreibung.
| Prozess | Wer | Detail |
|---|---|---|
| <Mitglieder-Onboarding> | <Rolle> | <siehe Onboarding-Protokoll (Schicht 1)> |
| <Mitgliederaustritt> | <Rolle> | <siehe Austritts- & Trennungsprotokoll (Schicht 1)> |
| <Antragsveröffentlichung> | <Rolle> | <siehe Governance-Protokoll (Schicht 2)> |
| <Beitragserfassung> | <Rolle> | <siehe Binnenwirtschaftsprotokoll (Schicht 3)> |
| <Regelmäßige Sitzung> | <Moderation> | <Agenda-Veröffentlichung; Protokoll; Aufgabennachverfolgung> |
| <Kassenverwaltung> | <Finanzverantwortliche:r> | <siehe Kassenordnung (Schicht 3)> |
| <Überprüfung der Plattformzugänge> | <Infrastrukturverantwortliche:r> | <Prüfrhythmus; Zugangsentzug für ausgetretene Mitglieder> |
Was hineingehört
- Which processes have to keep happening for the community to work — onboarding, exit, publishing proposals, recording contributions, running meetings, managing money, reviewing platform access, and anything else?
- For each process: which role owns it, and what does it involve in two or three sentences?
- For each process: where are the steps written down, so someone new could carry it out without asking the person who usually does it? (Where our documents live in general is its own question.)
- Which of these still depends on one person's memory or goodwill — and who will write it up, by when?
- How do we keep each written process up to date when the way we actually do it changes? (Handoffs between roles are their own question.)
Beispiele
Our core processes are member onboarding and member exit (Membership Admin, following those protocols), proposal publication (Governance Secretary), contribution recording (Contribution Steward), the weekly meeting (rotating facilitator: agenda, notes, action list), treasury management (Finance Steward) and platform access review (Infrastructure Steward, monthly, removing exited members). Each has a one-page checklist in the shared handbook that a new role holder can follow without help, and the owner updates it within a week of any change in practice.
Beispiele, keine Empfehlungen. Eure Antworten werden eure eigenen sein.
Temporäre und Ad-hoc-Verantwortlichkeiten
How do we stop a temporary favour becoming somebody's permanent unpaid job?
RCOS-Klauseln 7.1.5, 7.1.4, 7.7.1
- 7.1.5 Temporäre oder Ad-hoc-Verantwortlichkeiten MUSS explizit zeitlich begrenzt sein und DARF NICHT ohne formale Rollendefinition dauerhaft werden.
- 7.1.4 Keine laufende Verantwortlichkeit KANN ohne eine explizite Rolle bestehen, und keine Person KANN für Verantwortlichkeiten zur Rechenschaft gezogen werden, die nicht formal einer Rolle zugewiesen sind.
- 7.7.1 Laufende Verantwortlichkeiten DARF NICHT ohne eine explizite Rolle bestehen.
Warum temporäre Verantwortlichkeiten begrenzen?
Ad-hoc-Aufgaben verfestigen sich still und leise zu dauerhaften, unbezahlten Jobs — meist bei der Person, die einmal Ja gesagt hat. Eine feste Zeitbegrenzung und eine erzwungene Überprüfung machen den Unterschied zwischen „Ich bin eine Woche eingesprungen" und „Anscheinend ist das jetzt meine Aufgabe."
Wie ihr das ausfüllt
Haltet fest, dass jede temporäre Verantwortlichkeit bei der Zuweisung zeitlich begrenzt, dokumentiert und vor Ablauf überprüft werden muss — und dann entweder formalisiert oder beendet wird.
Wenn eine Aufgabe oder Verantwortlichkeit temporär zugewiesen wird, muss sie:
- <Von Anfang an ausdrücklich zeitlich begrenzt sein (konkretes Enddatum oder Abschlussbedingung).>
- <Zum Zeitpunkt der Zuweisung als temporär dokumentiert werden.>
- <Vor dem Enddatum überprüft und entweder in eine formale Rolle überführt oder beendet werden.>
<Maximale Dauer einer temporären Verantwortlichkeit, bevor sie formal zugewiesen oder beendet werden muss — z. B. 90 Tage.> Wenn eine temporäre Verantwortlichkeit nach ihrem Enddatum keine verantwortliche Person hat, erlischt sie; sie geht nicht stillschweigend auf jemand anderen über.
Was hineingehört
- When someone takes on a temporary task, how is its end set — a date, or a clear condition that marks it done?
- Where is it recorded as temporary at the moment it is handed out, and by whom?
- What is the longest a temporary responsibility may run, extensions included, before it must become a formal role or stop?
- Who checks on it before the end date, and how is it either ended or turned into a proper role? (Defining the new role is a Role Registry question.)
Beispiele
Every temporary task is given with an end date or a clear "done when" condition and logged as temporary on the task board by whoever assigns it. A week before it ends, the assigner and the person doing it check in: the task either ends, or it is proposed as a new role for the Role Registry. No temporary responsibility may run longer than 90 days in total, extensions included.
Beispiele, keine Empfehlungen. Eure Antworten werden eure eigenen sein.
Rollen- und Zuständigkeitsschnittstellen
Where does one role's work end and the next one's begin?
RCOS-Klauseln 7.6.3, 7.3.4
Warum Übergaben explizit abbilden?
Die meisten Betriebsfehler passieren nicht innerhalb einer Rolle, sondern zwischen Rollen — an den Schnittstellen, wo Arbeit von einer verantwortlichen Person zur nächsten wandert. Die Übergaben zu benennen macht unsichtbare Abhängigkeiten überprüfbar und verhindert „Ich dachte, du hättest dich drum gekümmert"-Situationen.
Wie ihr das ausfüllt
Benennt für jedes Rollenpaar, das Arbeit weitergibt, die Übergabe und die Art der übertragenen Arbeit.
| Von | An | Übergabe |
|---|---|---|
| <Rolle> | <Rolle> | <was übergeben wird> |
| <Rolle> | <Rolle> | <...> |
Was hineingehört
- Which roles regularly pass work to each other?
- For each handoff: what is handed over, in which direction, and how does the receiving role know it has arrived?
- At what point does the work stop being the first role's responsibility and become the next one's?
- Where does work pass between a role and a meeting — for example, a decision that a role must then carry out?
- When a handoff gets dropped, who notices and who sorts it out?
Beispiele
Membership Admin to Infrastructure Steward: when a new member's trial starts, the admin posts their details in the access channel and the steward sets up accounts within three days; on exit the same route removes them. Finance Steward to Contribution Steward: at each month-end the finance steward shares amounts paid in so contribution records can be reconciled. Governance meeting to role holders: each adopted decision is assigned to a named role in the notes, and that role confirms it has picked it up.
Beispiele, keine Empfehlungen. Eure Antworten werden eure eigenen sein.
Belastungsgrenzen
How much time, meeting and care can we ask of one person — and what happens when someone is overloaded?
RCOS-Klauseln 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.7.3
- 7.4.1 Zeit, Aufmerksamkeit, Koordinationskapazität und emotionale Arbeit MUSS als endliche und begrenzte Ressourcen behandelt werden.
- 7.4.2 Die Gemeinschaft MUSS explizite Belastungsgrenzen definieren, darunter:
- 7.4.3 Belastungsgrenzen MUSS durch einen autorisierten Governance-Prozess überprüfbar und anpassbar sein.
- 7.4.4 Anhaltende Überlastung, Burnout-Risiko, chronische Nicht-Teilnahme oder Abhängigkeit von übermäßig engagierten Einzelpersonen MUSS Überprüfungs- oder Reparaturprozesse auslösen, wie in Schicht 4 definiert.
- 7.7.3 Sitzungsbelastung, Koordinationsaufwand und unbezahlte oder unsichtbare Arbeit MUSS begrenzt und überprüfbar sein.
Warum Belastungsgrenzen explizit machen?
Unbegrenzte Koordinationslast ist der Standard-Fehlermodus von Freiwilligengemeinschaften — sie brennt still die engagiertesten Mitglieder aus, bis sie gehen. Explizite, überprüfbare Grenzen machen Kapazität zu einer gemeinsamen Angelegenheit statt zu einer privaten Last.
Wie ihr das ausfüllt
Legt Grenzen für Sitzungsbelastung, Rollenbelastung, Reaktionszeit-Erwartungen und den Weg zur Neuverhandlung von Verantwortlichkeiten fest.
- Sitzungsbelastung: <Wiederkehrender Sitzungsrhythmus und maximale Dauer; Regeln für außerordentliche Sitzungen.>
- Rollenbelastung: <Obergrenze falls vorhanden; Regel zur Überlastungsmeldung; Lösungsfrist.>
- Reaktionszeit-Erwartungen: <Nicht-dringend asynchron; dringend betrieblich; sicherheitskritisch.>
- Neuverhandlung und Entlastung: <Verfahren zur Umverteilung von Verantwortlichkeiten; Lösungsfrist.>
- Anhaltende Überlastung: <Wie anhaltende Überlastung, Burnout-Risiko, chronische Nichtbeteiligung oder Abhängigkeit von überfunktionierenden Personen erkannt und in den Review- oder Reparaturprozess von Schicht 4 überführt wird.>
Was hineingehört
- How much meeting time can we ask of one person — how often, how long, and what counts as an extra meeting?
- How many roles or hours a week may one person carry — counting unseen work like hosting, cleaning up or emotional support?
- What reply times do we expect — for everyday messages, urgent operational matters and safety issues — and when is nobody expected to answer?
- When someone says they are overloaded, how is their work covered, handed on or shared out — and how quickly?
- What signs tell us there is a pattern — lasting overload, burnout, members going quiet, or everything resting on a few people — and which review or repair process does that start?
- How often do we review these limits, and how are they changed?
Beispiele
Recurring meetings take up at most four hours a month per person; an extra meeting needs 72 hours' notice. Nobody holds more than two roles or about eight hours a week, care and hosting work included. Messages get a reply within three days, urgent operational ones within a day, safety issues at once. Anyone can say they are overloaded, and their tasks are reshared within two weeks; overload flagged twice in a quarter goes to our review-and-repair process. These limits are reviewed yearly and changed by proposal.
Beispiele, keine Empfehlungen. Eure Antworten werden eure eigenen sein.
Betriebliche Kontinuität
If any one of us disappeared for a month, what would stop working?
RCOS-Klauseln 7.5.1, 7.5.2, 7.5.3
Warum jetzt schon Kontinuität planen?
Eine Gemeinschaft, die von einer einzigen unersetzlichen Person abhängt, ist nur eine Krankheit, einen Konflikt oder einen Austritt vom Zusammenbruch entfernt. Die Single Points of Failure ehrlich zu benennen — und Übergaben in jede Rolle einzubauen — ist das, was die Gemeinschaft ihre Gründer:innen überleben lässt.
Wie ihr das ausfüllt
Benennt die aktuellen Single Points of Failure ehrlich. Haltet die Übergabe-Anforderungen pro Rolle und den Rhythmus der Kontinuitätsüberprüfung fest.
- Aktueller Stand: <Ehrliche Auflistung der Single Points of Failure; Rekrutierungsplan zur Verringerung der Konzentration.>
- Übergabe-Mechanismen: <Verweis auf die Übergabe-Anforderungen pro Rolle im Rollenregister; Übergabe muss abgeschlossen sein, bevor eine Rolle aufgegeben wird.>
- Rhythmus der Kontinuitätsüberprüfung: <Vierteljährlich; ad hoc bei Rollenwechsel.>
Was hineingehört
- Honestly, who or what is a single point of failure today — a person, account, key or skill that only one of us has?
- For each one: what is our plan to share it, and by when?
- For each core role and process: is the procedure written down, and what must be handed over before the holder leaves?
- Who backs up each core role — and where is a backup not yet possible?
- How often do we review this, and what else triggers a review, such as a role changing hands?
Beispiele
Today only one member can access the bank account and only one understands the water system. By March a second bank signatory will be added, and the water system will have a written guide and a trained deputy. Every core role has a named backup and a handover checklist that must be completed before the holder steps down. The Infrastructure Steward reviews this list every quarter and whenever a role changes hands.
Beispiele, keine Empfehlungen. Eure Antworten werden eure eigenen sein.
Informationsfluss und Anti-Gatekeeping
How do we make sure nobody has to go through one person to find something out?
RCOS-Klauseln 7.3.5, 7.7.4, 7.3.2
Warum Informationszugang als Governance-Thema behandeln?
Wer den Zugang zu Informationen kontrolliert, kontrolliert die Gemeinschaft — ob beabsichtigt oder nicht. Zugriffsregeln explizit zu machen — und alleinige Zugangspunkte zu untersagen — verhindert, dass informelle Gatekeeper die Art von Macht ansammeln, die das Governance-System eigentlich kontrollieren soll.
Wie ihr das ausfüllt
Haltet fest, welche Unterlagen allen Vollmitgliedern zugänglich sind, wie lang die Antwortfrist für Informationsanfragen ist und welche Regel gegen alleinige Zugangspunkte für governance-relevante Informationen gilt.
- <Governance-Entscheidungen sind für alle Vollmitglieder zugänglich.>
- <Sitzungsprotokolle werden innerhalb von X Stunden veröffentlicht.>
- <Mitgliedschaftsstatus und Rollenzuweisungen sind einsehbar.>
- <Beitragsnachweise sind einsehbar.>
- <Antwortfrist für Informationsanfragen.>
- <Das Zurückhalten von Informationen, auf die Mitglieder Anspruch haben, ist ein Rechenschaftsauslöser gemäß Schicht 4.>
- <Keine Rolle und keine Einzelperson darf der alleinige Zugangspunkt für Informationen sein, die andere Rolleninhaber:innen benötigen.>
Was hineingehört
- Which records can every Full Member open directly, without asking anyone — decisions, meeting notes, roles, membership, contributions? (Restricted and private records are their own question.)
- How soon after a meeting must notes and decisions be published?
- When someone asks for information they are entitled to, who must answer, and within how long?
- How do we make sure no single person or role is the only way in to information others need — passwords, files, contacts?
- What happens when someone holds back information a member is entitled to?
Beispiele
Every Full Member can read decisions, meeting notes, role assignments, membership status and contribution records in the shared drive without asking anyone. Meeting notes are posted within 48 hours. Any other request for information a member is entitled to is answered within five days. Every shared account and folder has at least two people with access, and withholding information a member is entitled to is treated as an accountability issue under our conflict process.
Beispiele, keine Empfehlungen. Eure Antworten werden eure eigenen sein.
Dokumentationsstandorte und Aktualisierungsverfahren
What do we write down, where, and who may read it — and can every decision be traced to who made it and how?
RCOS-Klauseln 7.3.1, 7.3.2, 7.3.3, 7.8.1
Warum festhalten, wo jedes Dokument lebt?
Wenn niemand sagen kann, wo die kanonische Version von etwas liegt, gibt es keine kanonische Version. Für jeden Dokumenttyp den Ablageort, die verantwortliche Person und den Überprüfungsrhythmus zu benennen, macht das Gedächtnis der Gemeinschaft auditierbar statt folkloristisch.
Wie ihr das ausfüllt
Benennt für jeden Dokumenttyp den kanonischen Ablageort, die verantwortliche Person und den Überprüfungsrhythmus.
| Dokumenttyp | Ablageort | Verantwortlich | Überprüfungsrhythmus |
|---|---|---|---|
| <RCOS-Artefakte> | <Ablageort> | <Verantwortlich> | <Rhythmus> |
| <Mitgliederregister> | <Ablageort> | <Verantwortlich> | <Rhythmus> |
| <Sitzungsprotokolle> | <Ablageort> | <Verantwortlich> | <Rhythmus> |
| <Governance-Anträge> | <Ablageort> | <Verantwortlich> | <Rhythmus> |
| <Beitragsnachweise> | <Ablageort> | <Verantwortlich> | <Rhythmus> |
Was hineingehört
- For each kind of record — our governance documents, member registry, meeting notes, proposals, contribution records: where does the official copy live, who keeps it, and how often is it reviewed?
- What must be written down about decisions, roles, day-to-day operations and shared obligations — what does each record have to contain at minimum?
- Who may read which records, and which are restricted for privacy — on what grounds, and who may still see them?
- When must a new record be published or announced, and to whom?
- Does every decision record say what type of decision it was and which area it covers, who had the authority, how it was decided and by what threshold, the outcome, and when it takes effect?
- Where can anyone find, written down, our roles, who may decide what, our meeting types, and our access and privacy rules?
Beispiele
Governance documents, the member registry and proposals live in the shared drive, kept by the Secretary and reviewed yearly; meeting notes and contribution records live on the wiki, kept by each facilitator and the Contribution Steward and reviewed quarterly. Every decision record states its type and area, who decided, the mechanism and threshold, the outcome and its start date, and is announced within three days. Members can read everything except health, safeguarding and conflict records, which only the people involved and two named stewards may see.
Beispiele, keine Empfehlungen. Eure Antworten werden eure eigenen sein.
Ratifizierungsnachweis
- Angenommen: <JJJJ-MM-TT>
- Entscheidungstyp: Strategisch
- Version: <Version>
- Entscheidungsnachweis: <Link zum Entscheidungsnachweis>