Copiki Freigabe-Workflow einrichten: Bearbeiten, prüfen, freigeben ohne E-Mail-Schleifen

Wo landen Ihre Freigaben heute – im Copiki oder in E-Mails und Chats? In vielen KMU entsteht genau dort das Problem: Die Seite in Copiki ist „irgendwie aktualisiert“, aber die Freigabe steht in einem Chatverlauf, den später niemand mehr findet. Nach ein paar Wochen ist unklar, wer geprüft hat, welche Version gilt und ob die Änderung wirklich freigegeben ist.

Ein guter Workflow macht das nicht bürokratischer, sondern verlässlicher: Zuständigkeiten sind sichtbar, Reviewer und Approver sind im System „am Zug“, und die Freigabe ist an einen konkreten Stand gekoppelt. In dieser Anleitung richten Sie in Copiki einen schlanken „Bearbeiten → Prüfen → Freigeben“-Workflow ein – mit begrenztem Startrecht, automatischer Zuweisung und einem Rücksprungpfad, wenn der Review ablehnt.

Was ein Wiki-Freigabe-Workflow leisten muss, damit er genutzt wird

Damit ein Copiki-Freigabe-Workflow im Alltag angenommen wird, muss er vor allem eines leisten: Er trennt „in Arbeit“ von „gültig“. Teams dürfen Inhalte vorbereiten und verbessern, aber alle sollen schnell erkennen können, welcher Stand freigegeben ist und damit als Standard gilt. In Copiki ist dieses Prinzip typischerweise an ein „Entwurf/Freigabe“-Modell gekoppelt, das je nach Setup über eine Freigabe-Funktion („Approval“) und einen Freigabestatus läuft. Wichtig ist weniger der Name als die Wirkung: Es gibt eine verlässliche, freigegebene Version.

Die Minimalanforderungen sind pragmatisch: Sie brauchen definierte Rollen, einen klaren Startpunkt (Trigger), ein dokumentiertes Ergebnis und eine Rücksprunglogik bei Ablehnung. Dann sinkt die Zahl der Rückfragen, Parallelversionen werden weniger, und in Audits ist der Weg zur Entscheidung kürzer – weil Prüfpfad und Status im System auffindbar sind. Entscheidend: Der Workflow ist nicht „fürs Audit“, sondern eine Routine für Prozesseigner und Reviewer. Wird er zu komplex, weichen Teams wieder auf E-Mail aus.

[Beispiel] Die Arbeitsanweisung „Wareneingang prüfen“ soll ergänzt werden. Die Produktion bereitet die Änderung im Wiki vor. Erst nach Review und Freigabe gilt die neue Version als verbindlich – und alle sehen in Copiki, welcher Stand der gültige ist.

Rollen klären: Editor, Reviewer, Approver – und warum das die QM-Stelle entlastet

Rollen sind der Hebel, damit Freigaben nicht an einzelnen Personen hängen bleiben. Wenn klar ist, wer fachlich pflegt, wer prüft und wer final freigibt, läuft die Arbeit dort, wo sie hingehört: in den Fachbereichen. Die QM-Stelle kann steuern und Kriterien setzen, ohne jede Änderung selbst „durchklicken“ zu müssen. (So bauen Sie Rollen und Dokumentenlenkung mit Copiki auf)

In der Praxis hat sich diese Dreiteilung bewährt: Der Editor (oft Prozesseigner) pflegt Inhalte und darf den Freigabeprozess starten. Der Reviewer prüft Inhalt und Verständlichkeit und entscheidet bewusst „annehmen“ oder „ablehnen“. Idealerweise schreibt er nicht nebenbei den Text komplett um, damit die Rückgabe klar bleibt. Der Approver setzt die finale Freigabe und sorgt dafür, dass „freigegeben“ wirklich Aussagekraft hat. In Copiki-Standard-Workflows werden diese Rollen auch als drei unterschiedliche Teilnehmende abgefragt (Editor, Reviewer, Approver).

Planen Sie Stellvertretungen mit ein. Sonst hängt der Ablauf bei Urlaub oder Krankheit. Achten Sie auch auf einen typischen Stolperstein: Wenn Reviewer und Editor identisch sind, wird „Prüfung“ zur Selbstbestätigung – und verliert ihren Nutzen.

[Beispiel] Produktion pflegt die Seite (Prozesseigner/Editor), QS prüft (Reviewer), die Bereichsleitung gibt frei (Approver). Damit bleibt die Fachlichkeit im Fachbereich, und die Freigabe ist trotzdem belastbar.

Rechte so setzen, dass nicht jeder Workflows starten kann

Bevor Sie den Workflow bauen, entscheiden Sie zuerst: Wer darf sehen, wer darf starten, wer darf ändern? Genau hier entsteht Governance – ohne dass Sie Transparenz verlieren. Copiki trennt dafür Rechte auf Workflow-Ebene: Workflows verwalten, Workflows ausführen/fortsetzen und Workflows ansehen.

Für den Alltag heißt das: Startrecht geben Sie gezielt an Prozesseigner oder Bearbeitungsverantwortliche. Das ist die Gruppe, die fachlich verantwortlich ist und den Prozess im Tagesgeschäft treibt. Gleichzeitig sollen Mitarbeitende den Status sehen können, damit nicht wieder nachgefragt wird. Die Konfiguration selbst gehört in eine Admin-Rolle, damit der Ablauf stabil bleibt.

In der BlueSpice-Referenz werden unter anderem die Berechtigungen workflows-admin (verwalten), workflows-execute (starten und vorantreiben) und workflows-view (ansehen) beschrieben.

Diese drei Rechteebenen sollten Sie unterscheiden:

• Sichtrecht: Wer darf Workflows und ihren Status sehen (z. B. für Transparenz im Team)?
• Start- und Ausführungsrecht: Wer darf Workflows starten und Schritte abschließen (Prozesseigner, benannte Rollen)?
• Adminrecht: Wer darf Workflows anlegen/ändern und Trigger verwalten (Wiki-Admins, nicht „mal eben“ im Fachbereich)?
• Teilnehmerlogik: Wer wird im Workflow als Editor/Reviewer/Approver zugewiesen (inkl. Stellvertretung)?
• Lesbarkeit von Entwürfen: Wer darf Entwürfe sehen, wenn Sie mit Entwurf/Freigabe arbeiten (abhängig von Ihrer Konfiguration)?

[Beispiel] Gruppe „Prozesseigner“ darf starten (workflows-execute), Gruppe „Alle“ darf Status sehen (workflows-view), Gruppe „Wiki-Admin“ darf Workflows konfigurieren (workflows-admin).

Der konkrete Ablauf: Bearbeiten, prüfen, freigeben als einzelner Workflow

Jetzt wird es konkret: Sie bauen genau einen Standard-Workflow für Einzel-Freigaben, den Sie auf Seiten anwenden, die wirklich „gültig“ sein müssen (Prozessseiten, Arbeitsanweisungen, Richtlinien). Copiki liefert dafür Standard-Workflows, darunter einen qualitätsgesicherten Review mit den Rollen Editor, Reviewer und Approver. Dieser Workflow nutzt typische Bausteine wie PageCheckout (Sperren), EditPage (Bearbeiten), UserVote (Abstimmen), ApprovePage (Freigeben) und PageCheckin (Entsperren).

Wichtig für die Akzeptanz: Die Rücksprunglogik muss sauber sein. In BlueSpice ist für den qualitätsgesicherten Review beschrieben, dass bei Ablehnung durch den Reviewer der Workflow zurück zum Editor geht. Und im einfachen Freigabe-Workflow wird bei Ablehnung der nächste Schritt (ApprovePage) übersprungen. Das verhindert, dass Ablehnung „nebenbei“ im Chat geklärt wird, während im System alles offen bleibt.

Workflow in 6 Schritten

• Start: Der Prozesseigner (Editor) startet den Workflow direkt auf der betroffenen Seite und setzt die Teilnehmenden (Editor, Reviewer, Approver).
• Sperren für sauberes Arbeiten: PageCheckout sperrt die Seite für Nicht-Teilnehmende; je nach Phase kann nur der Editor bearbeiten.
• Bearbeiten: Der Editor überarbeitet die Seite im Wiki (EditPage) und schließt seinen Schritt ab.
• Prüfen mit Entscheidung: Der Reviewer stimmt ab (UserVote): „Annehmen“ führt weiter, „Ablehnen“ führt zurück zur Bearbeitung (mit Begründung im Schritt).
• Final freigeben: Der Approver schließt die Freigabe ab (ApprovePage). Wenn die Seite im Entwurfsstatus war, wird sie in den freigegebenen Status gesetzt.
• Abschluss und Entsperren: PageCheckin entsperrt die Seite; der Workflow endet, und die Freigabe ist im System nachvollziehbar.

[Beispiel] Die Prozessseite „Reklamationen“ wird aktualisiert: Prozesseigner startet, QS prüft innerhalb von 48 Stunden (Zielwert), Bereichsleitung gibt frei. Danach ist klar, welche Version gilt und wer entschieden hat.

Markieren, informieren, dokumentieren: So wird Abstimmung im System sichtbar

Der größte Praxisnutzen entsteht, wenn das System die Abstimmung sichtbar macht. Das beginnt mit klarer Zuordnung: Aufgaben gehen an konkrete Nutzer:innen (Reviewer, Approver) und nicht an „die Abteilung“. Damit ist jederzeit erkennbar, wer am Zug ist – und wer gerade nicht.

Workflows können Benachrichtigungen auslösen und sind in das Benachrichtigungssystem integriert. In den Standardbeschreibungen ist unter anderem vorgesehen, dass der Initiator eine E-Mail über das Abstimmungsergebnis erhält und dass am Ende ein Bericht per E-Mail versendet werden kann, wenn ein Empfänger hinterlegt ist. Welche Kanäle bei Ihnen aktiv sind (Web, E-Mail oder beides), hängt von Ihrer Konfiguration ab. Prüfen Sie das in den Einstellungen.

Für die Nachvollziehbarkeit zählt am Ende die Kopplung an einen konkreten Stand: Die Freigabe sollte an eine Revision gebunden sein, sodass in der Seitenhistorie klar bleibt, welcher Stand „approved“ ist. Genau hier kommen Wiki und Dokumentenlenkung zusammen: Sie müssen nicht raten, welche Version aus einer Mail gemeint war. Der freigegebene Stand ist im System markiert und auffindbar.

[Beispiel] Der Reviewer lehnt ab und hinterlegt die Begründung im Workflow-Schritt. Der Prozesseigner bekommt die Rückmeldung automatisch, überarbeitet direkt im Wiki und startet nicht „noch eine“ Version in Word.

Quick Checks und typische Stolpersteine, bevor Sie live gehen

Bevor Sie live gehen, lohnt sich ein kurzer Realitätscheck. Ziel ist nicht, dass der Workflow „technisch läuft“, sondern dass er in Parallelprojekten und bei knappen Ressourcen genutzt wird. Prüfen Sie zuerst die Startberechtigung: Prozesseigner ja, alle nein – und Stellvertretung ist eingerichtet. Danach klären Sie, was „prüfen“ konkret heißt: fachlich korrekt, verständlich, Links und Nachweise aktuell, keine offenen To-dos.

Setzen Sie außerdem eine realistische Durchlaufzeit als Ziel (zum Beispiel 48 Stunden für den Review) und eine ruhige Eskalationsregel: Wer erinnert wen, und wann? Wenn Dateien/Anhänge betroffen sind, treffen Sie eine klare Regel: Läuft die Freigabe über die Seite, die die Datei einbettet, oder brauchen Sie einen separaten Prozess für Dateien? Das hängt davon ab, wie Sie Attachments in Copiki nutzen und was bei Ihnen als „Dokument“ gilt. Bleibt das offen, entstehen schnell Schattenablagen.

[Beispiel] Pilotieren Sie den Workflow zuerst auf drei kritischen Prozessseiten. Erst wenn Durchlaufzeit und Akzeptanz passen, rollen Sie den Ablauf breiter aus.

Fazit

Ein Wiki-Freigabe-Workflow ist keine Zusatzschleife, sondern eine Entscheidungshilfe: Er macht sichtbar, wer verantwortlich ist, wer prüft und welcher Stand gilt. Der wichtigste Schritt passiert deshalb vor der Technik. Legen Sie Rollen und Startrechte so fest, dass Fachbereiche wirklich handeln können – ohne Wildwuchs, aber auch ohne dass die QM-Stelle jeden Startknopf drücken muss. Wenn das sitzt, entsteht eine belastbare Spur im System: Bearbeitung, Review, Freigabe und Rücksprung sind nicht „irgendwo besprochen“, sondern nachvollziehbar erledigt.

Strategisch ist das ein kleiner, aber wirkungsvoller Schritt Richtung Governance, die im Tagesgeschäft funktioniert: Entscheidungen werden dort getroffen, wo die Fachlichkeit liegt, und bleiben trotzdem dokumentiert. Halten Sie die Schrittfolge schlank und bauen Sie den Rücksprungpfad fest ein. Ablehnung darf nicht automatisch wieder zur Chat-Abstimmung führen. Gleichzeitig entlasten Sie Ihr Team, wenn Benachrichtigungen und klare Zuweisungen verlässlich greifen. Der letzte Hebel ist die Kopplung an eine konkrete Version – dann ist jederzeit klar, was freigegeben ist und was noch Entwurf ist.

Sie müssen nicht sofort perfekte Prozesslandschaften bauen. Wenn Sie eine Seite sauber durch Bearbeiten, Review und Freigabe bringen, haben Sie den Ablauf im Griff – und können ihn Schritt für Schritt ausweiten. Nehmen Sie sich als nächsten Schritt eine kritische Prozessseite vor, benennen Sie Prozesseigner, Reviewer und Approver und lassen Sie genau eine Änderung komplett über den Workflow laufen – inklusive dokumentierter Freigabe. Danach sehen Sie im Team schnell, welche Regel (Rechte, Kriterien, Stellvertretung) den nächsten Durchlauf einfacher macht als die letzte E-Mail-Schleife.

Häufige Fragen

Workflow-Check für Copiki: Rollen, Rechte, Freigabekriterien

Wenn Sie möchten, prüfen wir gemeinsam in einem kurzen Workflow-Check, ob Rollen, Rechte und Freigabekriterien in Copiki so gesetzt sind, dass der Ablauf wirklich im Fachbereich läuft – und nicht wieder in E-Mail-Schleifen kippt. Als Einstieg reicht oft ein Pilot auf einer Seite plus ein sauberer Rechte-Schnitt.

Als nächster Schritt passt auch ein kompakter Workshop zum Rollen- und Rechtemodell (Prozesseigner, Reviewer, Approver) inklusive Pilot-Workflow. Mehr Kontext zu Copiki finden Sie auf Copiki im Überblick oder als Ergänzung zur Anleitung in Ihren Copiki Hilfeseiten.

Quellen

• BlueSpice Helpdesk: Manual – Extension/Workflows
• BlueSpice: Manual – Extension/FlaggedRevs
• MediaWiki: Extension:FlaggedRevs (EN)
• MediaWiki: Help – Extension:FlaggedRevs
• BlueSpice: Release Notes – BlueSpice 4
• BlueSpice: Release Notes (PDF, DE)

KI unterstützt, Menschen entscheiden – so sichern wir Qualität, Relevanz und Verantwortung.