Die Schaltfläche „Entlassen“ in Bitrix24 (Alaio) entzieht dem Mitarbeiter den Zugriff auf das Portal und sonst nichts: Seine Deals, Aufgaben, Beobachterrollen und Webhooks bleiben bei ihm. Die Standardwerkzeuge für die Übergabe gibt es, aber sie sind verstreut, manuell und decken nicht jede Rolle ab. Dieser Artikel geht durch, was beim Ausscheidenden bleibt, wie man es mit den Standardwerkzeugen übergibt und wo Roboter der einzige Weg sind: verknüpfte CRM-Datensätze, Mitwirkende und Beobachter in Aufgaben, Integrationen, die mit dem Token des Ausscheidenden laufen, und Automatisierungsregeln, in die die Annahme „der Mitarbeiter ist aktiv“ fest eingebaut ist.
Was passiert bei der Entlassung, und was bleibt hängen?
Die Entlassung nimmt ein Administrator vor oder ein Mitarbeiter mit der Berechtigung „Mitarbeiter entlassen“ in der Unternehmensstruktur: „Entlassen“ im Menü der Mitarbeiterliste oder „Aktionen → Entlassen“ im Profil. Der Mitarbeiter verliert den Zugriff, wird aber nicht gelöscht: Aufgaben, Nachrichten und Dateien bleiben erhalten, und das Profil wandert in den Reiter „Entlassene“, der in der Liste standardmäßig ausgeblendet ist. Hatte der Mitarbeiter aktive Integrationen, fragt das Portal, ob sie deaktiviert oder beibehalten werden sollen – dazu weiter unten mehr. Alles andere bleibt, wie es war: Der Ausscheidende ist weiterhin Verantwortlicher für Deals und Kontakte, Ausführender und Ersteller von Aufgaben, Beobachter in Karten, Mitglied von Chats und Gruppen. Automatisierungsregeln und Geschäftsprozesse, die ihm Aufgaben zuweisen oder Benachrichtigungen schicken, tun das weiter – ins Leere. Offboarding in Bitrix24 ist also keine Schaltfläche, sondern eine Checkliste über vier Bereiche: CRM, Aufgaben, Integrationen, Automatisierung.
Wie übergebe ich Deals, Leads, Kontakte und Unternehmen?
Der Standardweg ist eine Massenaktion in der Liste: CRM-Bereich, Ansicht „Liste“, Filter „Verantwortlich“ (für einen Ausscheidenden der Reiter „Entlassene“ in der Mitarbeiterauswahl), die Karten anhaken, „Aktion auswählen → Verantwortlichen ändern“; das Kontrollkästchen „Für alle“ wendet die Aktion auf alle Seiten der Auswahl an. Das funktioniert für Leads, Deals, Kontakte, Unternehmen, Angebote und Aktivitäten; Rechnungen werden einzeln aus der Rechnungskarte übergeben, und ist der Mitarbeiter bereits entlassen, muss er dafür vorübergehend wieder „eingestellt“ werden. Übergeben Sie auch abgeschlossene Datensätze: Anrufe und Benachrichtigungen erreichen dann bei Wiederaufnahme der Arbeit den neuen Verantwortlichen. Der Schwachpunkt der Massenaktion ist, dass sie nichts von Verknüpfungen weiß: Sie übergeben die Unternehmen, und deren Kontakte und Deals bleiben beim Ausscheidenden. Der Roboter „Verantwortlichen bei verknüpften ändern“ schließt genau diese Lücke: Auf einem Unternehmen gestartet, weist er dessen Deals oder Kontakte neu zu; auf einem Kontakt – dessen Deals oder Unternehmen; bis zu 500 Datensätze pro Lauf. Soll der Bestand nicht an einen Nachfolger gehen, sondern auf ein Team verteilt werden, wählt der Roboter „Verantwortlichen zuweisen: Warteschlange / Auslastung“ den nächsten der Reihe nach oder den am wenigsten ausgelasteten; ein Massenstart mit Filter „Verantwortlich“ startet den Geschäftsprozess auf allen Deals des Ausscheidenden auf einmal. Manueller, massenhafter und automatischer Wechsel im Detail – im Artikel über den Wechsel des Verantwortlichen.
Wie übergebe ich Aufgaben: Ausführender, Ersteller, Mitwirkende und Beobachter?
Die Aufgaben eines Ausscheidenden weist ein Administrator neu zu: Mitarbeiterprofil → Reiter „Aufgaben“ → ein Filter wie „In Arbeit“ → die Aufgaben anhaken oder „Für alle“ → „Aktion auswählen“ → „Ausführenden ändern“ oder „Ersteller ändern“. Ein Vorgesetzter kann die Aufgaben seiner direkten Mitarbeiter neu zuweisen, aber nur die, in denen er selbst Ersteller oder Ausführender ist. Zwei Rollen berührt die Standardübergabe nicht: Mitwirkende (Teilnehmer) und Beobachter. Der Ausscheidende bleibt Mitwirkender in Dutzenden Aufgaben und Beobachter in Hunderten, und jede davon wartet weiter auf eine Reaktion, die nie kommt. Aus einem Geschäftsprozess heraus ist das in einem Durchgang erledigt: „Aufgabe per ID aktualisieren“ überschreibt die Felder ACCOMPLICES und AUDITORS mit einer Liste von Benutzer-IDs, „Beobachter der Aufgabe ändern“ entfernt einen Beobachter, ohne die übrigen anzutasten, und „Auftraggeber der Aufgabe ändern“ überträgt die Erstellerrolle auf den Nachfolger, wo die Massenaktion nicht verfügbar ist. Wer in einer Aufgabe wer ist und wie man diese Rollen automatisch verwaltet – im Artikel über Beobachter und Mitwirkende.
Was passiert mit den Webhooks und Integrationen des Ausscheidenden?
Ein Webhook führt seine Anfragen mit den Berechtigungen des Mitarbeiters aus, der ihn angelegt hat, und sein geheimer Code ist nur für diesen Mitarbeiter sichtbar. „Die ausgehenden Webhooks funktionieren seit dem Ausscheiden des Mitarbeiters nicht mehr“ ist also keine Störung, sondern eine direkte Folge. Bei der Entlassung bietet das Portal eine Wahl an: „Integrationen deaktivieren“ – die Webhooks stoppen; „Integrationen beibehalten“ – sie wandern zu einem Systembenutzer, einer Kopie des Ausscheidenden, und laufen weiter. Die zweite Option ist bequem, aber das Portal selbst warnt, dass der Zugriff auf die Daten über diese Webhooks bestehen bleibt und jeder mit dem Link ihn nutzen kann. Die vernünftige Reihenfolge: Vor der Entlassung auflisten, welche Integrationen, Websites und Dienste über die Webhooks dieser Person laufen, sie unter einem eigenen Dienstkonto mit minimalen Berechtigungen neu anlegen und erst dann mit deaktivierten Integrationen entlassen. Ist die Entlassung schon geschehen und etwas ausgefallen, zuerst den Webhook-Fehler eingrenzen; danach kann ein Administrator den Webhook eines anderen Benutzers bearbeiten – der geheime Code wird neu erzeugt, und der Administrator wird zum Eigentümer. Wie Webhooks grundsätzlich funktionieren – im Übersichtsartikel.
Wie entferne ich den Ausscheidenden aus CRM-Beobachtern und Automatisierungsregeln?
In den Karten von Deals, Leads, Kontakten und Unternehmen ist der Beobachter ein eigenes Feld, und die Entlassung leert es nicht. Der Roboter „Beobachter verwalten“ im Modus „Entfernen“ nimmt den Mitarbeiter aus der aktuellen Karte; massenhaft per Filter gestartet, bereinigt er den ganzen Bestand. Die zweite unsichtbare Spur ist der Mitarbeiter in den Automatisierungseinstellungen: eine Regel „Aufgabe für Mitarbeiter“ mit seinem Namen, eine an ihn adressierte Benachrichtigung, ein Genehmiger in einem Geschäftsprozess, ein Ersatzverantwortlicher in der Lead-Verteilung. Einen Standardbericht „wo ist diese Person in Automatisierungsregeln eingetragen“ gibt es nicht, also Pipelines und Vorlagen von Hand durchgehen: nach Nachnamen in der Regelliste jeder Phase und in den Parametern der Prozessvorlagen filtern. Damit sich ein solcher Rattenschwanz gar nicht erst bildet, sollte man Personen nicht namentlich in Regeln eintragen, sondern den Adressaten aus der Struktur nehmen – „Vorgesetzten des Mitarbeiters abrufen“ liefert den aktuellen Vorgesetzten des Verantwortlichen, nicht denjenigen, der es vor sechs Monaten war.
Wie baue ich eine Regel mit der Bedingung „Mitarbeiter ist entlassen“?
Eine häufige Anfrage: Die Regel soll bemerken, dass der Verantwortliche entlassen wurde, und den Deal neu zuweisen oder aufhören, ihm Aufgaben zu stellen. Standardbedingungen in Regeln prüfen die Felder der Karte, und das Aktiv-Kennzeichen eines Mitarbeiters ist kein Kartenfeld, also gibt es eine solche Bedingung nicht direkt, und die Deals des Ausscheidenden laufen wie alle anderen weiter durch die Pipeline. Die praktische Antwort ist nicht, diesen Zustand abzufangen, sondern ihn zu verhindern: CRM und Aufgaben am Tag der Entlassung nach den obigen Schritten übergeben und spätere Leads nicht an eine namentlich genannte Person, sondern über die Lead-Verteilung in die Warteschlange der Abteilung leiten. Ein Roboter „Ist der Mitarbeiter aktiv?“ – nimmt eine ID, gibt J/N und die ID des Vorgesetzten zurück – ist noch nicht in der Roboteka-Bibliothek; genau für solche Fälle wächst die Bibliothek: Beschreiben Sie die Aufgabe, wir bauen ihn kostenlos und nehmen ihn in den gemeinsamen Katalog auf.
Offboarding-Checkliste für Bitrix24
Vor dem Klick auf „Entlassen“: die Liste der Integrationen und Webhooks des Mitarbeiters, ersetzt durch ein Dienstkonto; Übergabe des Postfachs und der Kontakt-E-Mail. Am Tag selbst: CRM – massenhaft aus der Liste mit „Für alle“, danach der Roboter für verknüpfte Datensätze; Rechnungen – einzeln; Aufgaben – Ausführender und Ersteller aus dem Profil, Mitwirkende und Beobachter – per Roboter; CRM-Beobachter – per Roboter; „Integrationen deaktivieren“ im Entlassungsdialog. Danach: ein Durchgang durch Regeln und Prozessvorlagen, in denen der Ausscheidende genannt ist, und eine Prüfung der Zugriffsrechte des Nachfolgers – sonst erhält er Deals, die er nicht sehen kann. Am einfachsten hält man das zusammen mit einem Geschäftsprozess „Offboarding“ auf einem HR-Smart-Prozess, in dem Mitarbeiter und Nachfolger Felder des Elements sind und die Schritte die oben genannten Roboter.
Fazit
Offboarding in Bitrix24 sind vier Bereiche, nicht eine Schaltfläche. Das CRM wird aus der Liste übergeben; verknüpfte Datensätze – mit dem Roboter „Verantwortlichen bei verknüpften ändern“ oder über eine Abteilung hinweg mit „Verantwortlichen zuweisen: Warteschlange / Auslastung“; Aufgaben – Ausführender und Ersteller mit der Standardaktion, Mitwirkende und Beobachter über „Aufgabe per ID aktualisieren“ und „Beobachter der Aufgabe ändern“; CRM-Beobachter – „Beobachter verwalten“; Webhooks – vor der Entlassung unter einem Dienstkonto neu angelegt. Alle Roboter stehen im Roboteka-Katalog, kostenlos aus dem Bitrix24 Market. Fehlt ein Roboter für Ihren Offboarding-Schritt – beschreiben Sie die Aufgabe, wir bauen ihn kostenlos.