Dieser beitrag. Ein illustratives praxisbeispiel, kein kundenergebnis. Die dienstleistungsfirma und jede zahl sind annahmen. Es zeigt, wie ein interner ops-bot in Slack zugangsanfragen neuer mitarbeitender routen und freigeben kann, wobei jede aktion protokolliert wird.
Angenommen, eine professional-services-firma mit 40 personen. Team, prozess und zahlen sind annahmen für diese durchsicht, keine messungen eines kunden.
Der alte prozess ist nicht kaputt, weil menschen langsam sind. Er ist kaputt, weil ein neuer mitarbeiter accounts, tool-zugänge und ausstattung braucht und jede anfrage in einem anderen postfach liegt. Die ops-leitung jagt freigaben von hand. Zur veranschaulichung: angenommen, es dauert etwa drei werktage vom beginn des ersten tags bis zum funktionierenden laptop.
#Was frisst die zeit beim manuellen onboarding?
Nicht das klicken. Das warten. Eine anfrage für einen github-platz liegt, bis eine führungskraft die mail sieht. Eine anfrage für das finanztool wartet auf einen anderen freigeber. Niemand besitzt die übergabe, also stockt jeder schritt bei einer person. Die eigentliche arbeit ist ein kleiner bruchteil der verstrichenen zeit.
Wie automatisiert AI das onboarding, ohne ein weiterer chatbot zu werden?
Sie routet und gibt frei, sie fasst nicht nur zusammen. Ein ops-bot liest jede zugangsanfrage eines neuen mitarbeiters in Slack, prüft sie gegen eine rolle-zu-zugang-zuordnung und gibt dann risikoarme punkte selbst frei oder leitet riskantere mit freigabe per klick an den benannten verantwortlichen. Jede aktion wird protokolliert. Die zahl, die man beobachtet, ist die verstrichene zeit von der anfrage bis zum funktionierenden zugang.
#Wie sieht das design also aus?
Ein Bot, der dort lebt, wo die Arbeit ohnehin stattfindet. Wenn ein neuer Mitarbeitender angelegt wird, öffnet er einen Slack-Thread pro Person. Er liest die Rolle, ordnet sie einer definierten Zugriffsliste zu und bewegt jeden einzelnen Punkt. Accounts und risikoarme Tool-Plätze vergibt er nach Regeln, die der Kunde festgelegt hat. Alles Sensible, wie das Finance-System, routet er mit einem Genehmigen-oder-Ablehnen-Button an den namentlich benannten Owner.
- Ein Thread pro neuem Mitarbeitenden, sodass die gesamte Anfrage an einem Ort liegt, nicht in fünf Postfächern.
- Rollen-zu-Zugriff-Map im Besitz des Kunden, sodass die Regeln ihm gehören und auditierbar sind.
- Ein-Klick-Genehmigung für den Owner, sodass eine Entscheidung Sekunden dauert, nicht einen Tag E-Mail-Verkehr.
- Ein Offboarding-Trigger, der denselben Zugriff am letzten Tag eines Mitarbeitenden entzieht.
Der letzte punkt zählt mehr als die onboarding-geschwindigkeit. Den zugang eines ausgeschiedenen mitarbeiters zu entziehen ist der schritt, den alle vergessen. In diesem design wird er aus derselben zuordnung ausgelöst, die den zugang erteilt hat, sodass das offboarding so verlässlich ist wie das onboarding und verpasste entzüge zählbar werden.
We are
Stennir liefert einen Genehmigen-und-Routen-Ops-Bot, der eine Aktion ausführt und sie gegen eine Regel-Map im Besitz des Kunden protokolliert.
We aren't
Es ist kein Zusammenfassungs-Bot, der eine Anfrage liest und dir einen Absatz gibt, auf den du selbst noch reagieren musst.
#Wie vertraust du einem Bot, Zugriff zu genehmigen?
Du grenzt ein, was er entscheiden darf. Der Bot genehmigt automatisch nur die Punkte, die der Kunde in seiner eigenen Map als risikoarm markiert hat. Alles andere routet mit vollem Kontext im Thread an einen Menschen. Jede Gewährung, jedes Routing und jeder Entzug wird protokolliert. So kann die Ops-Leitung beantworten, wer wann worauf Zugriff bekommen hat, ohne fünf Tools zu öffnen. Das ist der Governance-Teil, und wir bauen ihn von Tag eins an ein, nicht danach.
Stell dir den ersten montag vor, an dem es läuft: ein neuer analyst hat vor dem mittagessen einen funktionierenden laptop und alle logins, wo das früher ein mittwochsproblem war. Das ist das ergebnis, auf das man hin entwirft und das man misst, kein ergebnis, über das wir berichten.
In einem echten projekt gehört der code dem kunden. Das passt zum anwendungsfall interner ops-bot unter ai-implementierung und hat dieselbe form wie die praxisbeispiele zu logistik und finanzen im journal. Gleiches muster, andere abteilung: anfrage lesen, regel prüfen, aktion ausführen, protokollieren.
Wenn dein Onboarding ein Stapel Postfächer und eine Person ist, die hinterherjagt, ist das genau die Form, die das hier behebt. Sag uns, was du baust, und wir sagen dir, ob ein Ops-Bot die richtige Wahl ist oder eine zweizeilige Automatisierung reichen würde. Sag uns, was du baust.
