この記事について. 説明用のワークド・エグザンプルであり、顧客の実績ではありません。サービス会社とすべての数字は仮定です。Slack内の社内運用ボットが、新入社員のアクセス申請を振り分けて承認し、すべての操作を記録する形を示します。
従業員40人のプロフェッショナルサービス会社を仮定します。チーム、プロセス、数字は解説のための仮定であり、顧客の測定値ではありません。
古いプロセスが壊れているのは、人が遅いからではありません。新入社員にはアカウント、ツールへのアクセス、機材が必要で、各申請が別々の受信箱にあるからです。運用担当者は手作業で承認を追いかけます。説明のため、初日の開始から使えるノートPCが手に入るまで、営業日で約3日かかると仮定します。
手作業のオンボーディングでは、何が時間を食うのですか
クリックではありません。待ち時間です。GitHubの席の申請は、マネージャーがメールに気づくまで止まります。財務ツールの申請は、別の承認者を待ちます。引き継ぎの持ち主がいないので、すべての手順が人のところで止まります。実作業は、経過時間のごく一部です。
AIは、もう一つのチャットボットにならずに、どう従業員のオンボーディングを自動化しますか
要約するだけでなく、振り分けて承認します。運用ボットはSlack内の新入社員のアクセス申請を読み、役割とアクセスの対応表と照合し、低リスクの項目は自分で承認し、リスクの高いものはワンクリック承認つきで指名された担当者に回します。すべての操作は記録されます。追うべき指標は、申請から使えるアクセスまでの経過時間です。
では、設計はどのようなものですか
実際の業務が行われている場所にそのまま存在するボットだ。新入社員が登録されると、ひとりにつきひとつのSlackスレッドが開く。役割を読み取り、定義済みのアクセスリストと突き合わせ、項目ごとに処理を進める。アカウントやリスクの低いツールの席は、クライアントが定めたルールに基づいてボットが自ら付与する。経理システムのような機微な項目は、承認・却下ボタン付きで担当の責任者にルーティングする。
- 新入社員ひとりにつきスレッドがひとつ。リクエスト全体が5つの受信箱ではなく一か所にまとまる。
- 役割とアクセス権の対応表はクライアントが所有し、ルールは自社のものであり監査可能。
- 責任者はワンクリックで承認でき、判断が1日がかりのメールのやり取りではなく数秒で済む。
- 退職日に同じアクセス権を取り消すオフボーディングのトリガー。
最後の項目は、オンボーディングの速さより重要です。退職者のアクセスを取り消すのは、誰もが忘れる手順です。この設計では、アクセスを付与したのと同じ対応表から取り消しが実行されるので、退職処理も入社処理と同じだけ確実になり、取り消し漏れは数えられるものになります。
We are
Stennirは、実際の操作を行いクライアント所有のルール対応表に照らして記録する、承認とルーティングを行う運用ボットを構築する。
We aren't
リクエストを読んで、あなたが結局対応しなければならない文章を渡すだけの要約ボットではない。
アクセス権の承認をボットに任せて信頼できるのか
ボットが判断できる範囲をあらかじめ定める。ボットが自動承認するのは、クライアント自身が対応表でリスクが低いと定めた項目だけだ。それ以外はすべて、スレッド内の文脈が全部そろった状態で人間にルーティングされる。付与、ルーティング、取り消しのすべてが記録される。だから運用リードは、5つのツールを開かなくても、誰がいつ何にアクセスできるようになったかを答えられる。これがガバナンスの部分であり、私たちは後から付け足すのではなく初日から組み込む。
動き始めた最初の月曜日を想像してください。新しいアナリストが、昼前に使えるノートPCとすべてのログインを手にしています。以前は水曜日の問題でした。これは設計して測る目標であって、私たちが報告する実績ではありません。
実際の案件では、コードはクライアントが所有します。AI導入の社内運用ボットのユースケースに当たり、ジャーナルのロジスティクスと財務のワークド・エグザンプルと同じ形です。同じパターンで、部門が違うだけです。申請を読み、ルールを確認し、操作を実行し、記録します。
あなたのオンボーディングが、山積みの受信箱とそれを追いかける担当者という形になっているなら、まさにこれが解決する形そのものだ。何を構築したいのか教えてほしい。運用ボットが適切な選択なのか、それとも2行の自動化で十分なのかをお伝えする。何を構築したいか教えてほしい。
