Публикация Школы траблшутеров

Как регламентировать онбординг и офбординг BI-аналитиков

Время чтения: 7 мин 40 сек
27 мая 2025 г. Просмотров: 49

Процессная эффективность, ПерсоналОлег Брагинский, Максим Мухтаров

Основатель «Школы траблшутеров» Олег Брагинский и ученик Максим Мухтаров рассказывают, как организовать адаптацию и передачу дел сотрудников, автоматизирующих обновление отчётности в отечественных многопрофильных медицинских учреждениях.

В крупной частной медицинской сети ширилось использование BI-системы, разрасталась команда. Поиск специалистов занимал от трёх до шести месяцев – требовалось ускорять выход нанятых на приемлемый уровень производительности и структурировать результаты работ выбывающих.

Сотрудники отдела кадров принимали на работу и обеспечивали минимальное оформление рабочего места, остальное входило в зону ответственности прямых руководителей. Увольнение также происходило централизованно, а передача дел осуществлялась внутри подразделений.

Предстояло описать процессы онбординга и офбординга: участников, этапы, операции. Поставили цель регламентировать собственные усилия: работу других структурных единиц мыслили чёрными ящиками. Скорость реагирования на запросы повышали точностью формулировок.

Онбординг включал три этапа:

  1. Сотрудник получает необходимый доступ.
  2. Руководитель вносит подчинённого в административные файлы.
  3. Сопровождающий коллега назначает задачи и встречи для обмена информацией.

Ресурсы по этапности подключения делились на: а) изначальные – доступ предоставляется в ходе оформления рабочего места по заявке, инициированной отделом кадров; б) дополнительные – сотрудник самостоятельно отправляет письма с запросами по инструкциям из базы знаний.

В день выхода HR-специалист высылал сотруднику ссылки на: а) веб-версию почтового клиента, б) мессенджер, в) таск-трекер; г) корпоративную wiki; д) GitLab. После создания учётной записи в Active Directory системные администраторы отправляли по СМС логин и пароль для первого входа.

Переданному кадровиком контакту начальник высылал URL раздела в базе знаний с инструкциями по самостоятельной донастройке изначальных ресурсов и запросу доступа к дополнительным. Статьи структурировали в два блока: а) алгоритм предоставления; б) действия после получения.

Вышедший сотрудник настраивал в MS Outlook подпись по образцу: «С уважением, <ФИО> <Должность> <Подразделение> <Юридическое лицо>», отделяя смысловые единицы переносами строки. Отправлял начальнику письмо с запросом включить в список общих встреч подразделения.

Во входящих создавал подпапки с правилами сортировки писем от определённых адресатов: УпРсД – коллеги из управления по работе с данными, ББ – блок по безопасности, СОО – служба одного окна, КР – корпоративные рассылки, HR – кадровая информация, СЭД – электронные документы.

В мессенджере заполнял профиль, подставляя в поля <Имя Фамилия> и <Должность Подразделения>. Загружал деловую фотографию. Отсылал руководителю письмо с запросом добавить в закрытые каналы вида team- и notify-<название проекта>, общий чат подразделения.

В таск-трекере заносил канбан-доски в избранное. Направлял начальнику запрос на добавление корпоративной учётной записи в репозитории GitLab. Права указывал по должности: аналитик и ведущий аналитик получали Developer, главный аналитик и руководитель проекта – Maintainer.

Доступ к дополнительным ресурсам получал по маршруту: а) подготовить письмо с текстом и с заполненным Word-файлом заявки во вложении (если предусмотрен); б) последовательно согласовать у руководителя, владельца, блока по безопасности; в) переслать в службу одного окна.

На обычную учётную запись предоставляли роли в корпоративных информационных системах, удалённый доступ по RDP к общему рабочему столу и компьютеру в офисе, сетевые папки. Логин администратора выдавали для подключения к виртуальным машинам и установки программ.

Для ускорения обработки заявок руководитель связывался с исполнителями по телефону. В компаниях с налаженными процессами вносить дополнительное дребезжание прямым эскалированием недопустимо, в остальных случаях нетворкинг – обязательный навык менеджера.

Файлы для инсталляции в необходимых версиях хранили в общей папке подразделения. ПО включало SQL Server Management Studio и надстройку SSMS Boost, DBeaver, Power BI Desktop, Report Builder, Visual Studio и расширения под SSAS и SSRS, PyCharm, python 3.9, Git for Windows.

Параллельно начальник вносил информацию о новом сотруднике в собственный Excel-файл: а) в строки вписывал должность и ФИО, б) в столбцах на разных вкладках указывал дату рождения, отпуска и больничные по дням, оклад и премии, КПЭ по кварталам, текущую оценку компетенций.

Старшего коллегу менеджер назначал по принципу «кого разгружает, тот и отвечает». Так создавалась максимальная заинтересованность «бадди» в адаптации новичка. При этом должность сопровождающего сотрудника предполагала хотя бы первый уровень по компетенции Руководство.

Встречи в календарь ответственный выставлял: а) на первой неделе – с 11:00 до 12:00 и с 17:00 до 18:00 ежедневно; б) на второй – с 11:00 до 12:00; в) на третьей – с 11:00 до 12:00 в понедельник, среду, пятницу; г) начиная с четвёртой и до конца испытательного срока – с 11:00 до 12:00 в пятницу.

Руководитель заводил родительскую карточку в таск-трекер для подтверждения компетенций нанятого в течение трёхмесячного периода, а сопровождающий сотрудник привязывал конкретные делегируемые и оцениваемые задачи путём добавления ссылок к соответствующим пунктам в теле.

Онбординг заканчивался прохождением испытательного срока. При положительном решении адаптирующийся должен был подтвердить нахождение на требуемом для должности уровне по 11 из 14 компетенций. По трём оставшимся допускалось получить значение на одну ступень ниже.

Полноценное прохождение офбординга возможно в случае увольнения по собственному желанию. Для минимизации рисков руководитель должен проектировать и контролировать повседневную работу сотрудников так, чтобы невыполнение чек-листов существенно не влияло на передачу дел.

После получения заявления начальник присылал в календарь две встречи на предпоследний и финальный день с 17:00 до 18:00 и создавал задачу в таск-трекере. В наблюдатели ставил подхватывающего работу. Второй слот резервировал под возможность исправить замечания:

Карточка включала чек-лист:

  1. Перечислить ссылки на открытые задачи.
  2. Сохранить SQL и python-скрипты в GitLab.
  3. Включить в связанные переписки коллегу.
  4. Отписаться о проделанном в комментариях.
  5. Провести брифинг принимающего сотрудника.
  6. Архивировать личные файлы в сетевую папку.
  7. Включить в MS Outlook бессрочные автоответы.

Пункты 2–4 уходящий исполнял по каждой из незавершённых задач – на канбан-доске находились до перехода в статус «Готово». Загружал файлы в репозитории по действующим инструкциям. Персональные документы выкладывал по пути: <Папка подразделения>\!СОТРУДНИКИ\<ФИО>.

«Отбивку» в почту настраивал для внутренних и внешних адресатов. Заполнял по шаблону: «Коллеги, добрый день! <Дата> увольняюсь из <Юридическое лицо>. По всем вопросам, с которыми Вы обращались ко мне, прошу писать <ФИО перенимающего> (<email>). <Подпись>».

Несмотря на непреложную истину «сотрудников ускорять нельзя», руководитель обязан минимизировать текущий и будущий простой ресурсов. Только потраченное на продумывание процесса время определит, станет ли человек самым узким или широким местом в системе.