Онбординг и оффбординг обычно держат в голове дежурного администратора: шаги несложные, но при потоке найма и увольнений память подводит — и молчит об этом. Смотрим на процесс как на жизненный цикл учётной записи: как её завести (событие «Новый сотрудник» и готовый шаблон), почему оффбординг запускают вручную, чем блокировка отличается от отзыва сессий и почему удаление учётки стоит последним пунктом. И главное — как журнал запусков «+Альянс Потока» отвечает на вопрос «а мы точно закрыли доступ уволенному» не памятью, а записью со статусом.
У корпоративной учётной записи есть срок жизни. Её заводят в тот день, когда человек выходит на работу. Дальше она обрастает доступами — к почте, к общим папкам, к календарям, к десятку рабочих групп. А однажды её нужно аккуратно закрыть, ничего не забыв. Между «завести» и «закрыть» — месяцы, а то и годы. И почти всегда ни строчки регламента: весь этот цикл живёт в голове того, кто в нужный день дежурил по кадрам.
Пока найм — событие раз в квартал, голова справляется. Ломается всё тогда, когда учётные записи заводят и гасят десятками, а помнит про них по-прежнему один человек.
Я хочу зайти в тему онбординга и оффбординга не с привычной стороны «какие шаги надо сделать» — их и так все знают. Меня интересует другой вопрос. Это у вас процесс или каждый раз небольшой подвиг памяти? И сможете ли вы через полгода доказать, что доступ уволенному действительно закрыли, а не «вроде бы»?
Разберу цикл по частям: как запись рождается, как живёт и как её правильно завершить. И где на каждом отрезке подводит память — а что можно поставить вместо неё.
Открытие: первый день, к которому всё уже готово
Рождение учётной записи в Яндекс 360 — это не одно действие «создать», а короткая цепочка. Дописать профиль: должность, подразделение. Перевести человека в нужный отдел. Добавить в рабочие группы, чтобы открылись доступы к общим папкам и календарям. Отправить приветственное письмо с логином, паролем и памяткой, куда заходить в первый день. Каждый шаг — пустяк. Беда в том, что этих пустяков много и повторяются они при каждом найме.
«+Альянс Поток» — сервис для автоматизации рутины в Яндекс 360. Он умеет ловить событие «Новый сотрудник» — момент, когда в организации создали учётную запись, — и дальше проходить всю цепочку сам: дозаполнить профиль, перевести в отдел, добавить в группы, отправить приветствие по почте. На этот случай в сервисе уже лежит готовый шаблон «Онбординг сотрудника» — берёте и подгоняете под свою структуру.
Тут же напрашивается ещё одно действие, про которое обычно вспоминают потом и отдельно, — поставить нового сотрудника под резервное копирование. «Поток» связан с «+Альянс Бэкапом» единой авторизацией, поэтому добавление в политику копирования встаёт в тот же сценарий одним узлом. Не «вернусь к этому как-нибудь на неделе», а сразу, в момент заведения.
Как это выглядит в жизни — зарисовка, намеренно условная. Кадровик создал учётку нового менеджера и закрыл ноутбук. Всё остальное происходит уже без него: профиль дозаполнен, человек в своём отделе и группах, на рабочую почту ушло письмо с доступами. К моменту, когда новичок сядет за стол, аккаунт уже живёт полной жизнью. Забыть какой-то шаг тут попросту негде: цепочку ведёт сценарий, и он не устаёт, не отвлекается и не уходит в отпуск.
Завершение: закрыть сложнее, чем открыть
Конец цикла — самая недооценённая его часть. Открыть доступ несложно хотя бы потому, что за этим следит сам новичок: не открыли — придёт и напомнит. А закрыть надо самому, до конца и вовремя. Напоминать некому: человек ушёл.
Вот что должно произойти, когда сотрудник увольняется: закрыть ему вход, оборвать активные сессии, сохранить рабочие данные, передать дела, предупредить кого следует — и только в самом конце удалить учётную запись. На этом маршруте есть две ловушки, в которые попадают чаще всего.
Первая — считать, что «заблокировал» и есть «закрыл доступ». Это разные вещи. Блокировка не даёт войти заново, но те сессии, что уже открыты, она не трогает. Бывший сотрудник, у которого на личном телефоне залогинена рабочая почта, продолжит спокойно её читать и после блокировки. Поэтому в сценарии сразу за узлом «Заблокировать пользователя» ставят «Отозвать сессии» — иначе полдела так и остаётся сделанным лишь на бумаге.
Вторая ловушка серьёзнее — поспешное удаление. Кажется логичным: уволился — удаляем запись, чтобы не мозолила глаза. Но вместе с учёткой из облака исчезают привязанные к ней данные, почта и файлы сотрудника, а там нередко лежит то, что компании ещё пригодится. Удалили сразу, хватились через неделю — восстанавливать уже нечего. Поэтому в жизненном цикле удаление стоит последним пунктом, а перед ним — сохранение: снять резервную копию и передать дела тому, кто подхватит.
Почему оффбординг запускают руками
Здесь резонно спросить: в Яндекс 360 же есть событие «Увольнение» — почему не повесить весь сценарий прямо на него и не запускать отключение автоматически, как онбординг?
Потому что «Увольнение» в этой системе — это и есть удаление учётной записи. Событие наступает ровно в тот момент, когда запись уже удалена, то есть когда спасать данные поздно. Поэтому оффбординг в «Потоке» запускают вручную: оператор стартует сценарий тогда, когда данные ещё на месте, — чтобы резервная копия успела снять их до удаления записи.
Порядок шагов в таком сценарии жёсткий: сначала согласование, затем резервное копирование и только потом удаление сотрудника из организации. Согласование — это отдельный узел с двумя ветками, «согласовано» и «отклонено». Пока согласующие не дали добро, бэкап не запускается, а значит, до удаления дело не доходит в принципе. Под весь этот маршрут — с согласованием, копированием и удалением в конце — в сервисе есть отдельный готовый шаблон; плюс в наборе лежит и более простой «Оффбординг при увольнении».
Конструктор вместо разработки
Ничего из этого не требует программиста. Сценарии собираются мышкой на визуальной доске: перетащили нужные узлы, соединили стрелками, где надо — добавили условие «если — иначе», цикл или ветвление. Имя, почту и отдел сотрудника система подставляет в шаги сама, по шаблонным переменным. Готовых заготовок в наборе восемь, и две из них — ровно про наш разговор: «Онбординг сотрудника» и «Оффбординг при увольнении». А если собираете первый поток с нуля, вас проведёт пошаговый тур из тридцати шагов.
Раздел «Шаблоны» в «+Альянс Потоке»: среди восьми встроенных заготовок — «Онбординг сотрудника» и «Оффбординг при увольнении».
Главное — результат можно доказать
И тут мы подходим к сути, ради которой процесс вообще стоит выстраивать. Скорость и экономия кликов — приятный бонус, но не главное. Настоящая ценность в другом: результат становится проверяемым.
В любой компании рано или поздно звучит вопрос — а мы точно закрыли доступ тому, кто ушёл полгода назад? Пока весь цикл держится в голове администратора, честный ответ на него будет «должны были». Спокойствия такой ответ не добавляет никому.
«Поток» отвечает иначе. В разделе «История потоков» фиксируется каждый запуск: какой сценарий сработал, на каком шаге завершился, прошёл целиком или упал с ошибкой — со статусом «Готово» или «Ошибка». Ответ на «точно ли закрыли» перестаёт быть чьим-то воспоминанием и становится строкой в журнале. Предсказуемость плюс доказуемость: сценарий каждый раз отрабатывает одинаково, и каждый раз остаётся след, что он отработал. Именно ради этого цикл и переводят из головы в процесс.
Журнал запусков «Потока» — раздел «История потоков»: по каждому запуску виден статус и шаг, на котором он завершился.
Если кадры ведут учёт в 1С
Во многих компаниях кадровый учёт ведётся в 1С, и приказ о приёме или увольнении оформляют именно там. Такой приказ через входящий вебхук способен сам поднять нужный поток — старт даёт не человек, а запись в 1С. Механику эту я здесь трогать не стану: она тянет на самостоятельную статью, а мы в этом тексте намеренно остаёмся в периметре Яндекс 360.
Доступ и статус: пара честных оговорок
Заходят в «Поток» по учётной записи Яндекс 360, через OAuth, а настраивать потоки могут только администраторы организации. Сам сервис облачный, данные обрабатываются в России.
И честная оговорка про импортозамещение, раз про него всё чаще спрашивают. В реестр российского ПО «Поток» пока не внесён. Российским его делают разработчик — компания «+Альянс» из России — и хранение данных внутри страны, но не запись в реестре. Появится запись — скажем; выдавать желаемое за факт не будем.
Итог: цикл, который не держат в голове
- Онбординг и оффбординг — это не список шагов, которые все и так знают, а жизненный цикл учётной записи. Ценность не в знании шагов, а в том, чтобы цикл каждый раз выполнялся одинаково.
- Заблокировать вход и закрыть доступ — не одно и то же. Пока не отозваны активные сессии, человек формально всё ещё внутри.
- Удаление учётной записи — последний шаг, а не первый. Сначала сохранить данные и передать дела.
- Оффбординг запускают вручную не из любви к ручному труду, а чтобы резервная копия успела снять данные до удаления записи.
- И то, что превращает автоматизацию в аргумент: журнал запусков, по которому видно, что доступ действительно закрыт.
Проще всего проверить это на своих учётных записях. «Поток» открыт на 30 дней бесплатно, банковскую карту привязывать не нужно — этого хватит, чтобы собрать оба сценария и погонять их на живых аккаунтах. А если не хочется разбираться в одиночку, соберём процесс под вашу оргструктуру на демонстрации.
