М Про Системс
رفتن به کانال در Telegram
Автоматизируем управление персоналом По вопросам заказа услуг обращайтесь: mp@mpros.ru @MikhailProtasov mpros.ru
نمایش بیشتر491
مشترکین
-124 ساعت
-37 روز
اطلاعاتی وجود ندارد30 روز
آرشیو پست ها
Завтра провожу вебинар "Обзор документации WebSoft HCM"
Уровень: базовый
🗓 15 апреля
🕑 11:00 мск
Ссылка
Ответьте на несколько вопросов и получите бесплатную консультацию!
Я вношу корректировки в наши услуги и продукты. В связи с этим хочу опросить нескольких людей про актуальные задачи по HR автоматизации и работе с WebSoft HCM.
Приглашаю вас написать мне если:
◽️Вы работаете в крупной организации (от 1000 человек) или организуете массовое онлайн обучение
◽️Для вас актуальны задачи автоматизации управления персоналом
◽️Вы работаете в HR подразделении, либо занимаетесь проектами автоматизации HR в IT департаменте или другом подразделении
◽️Не получали бесплатную консультацию от меня ранее
При этом неважно, работали ли вы ранее со мной и используете ли вы систему WebSoft HCM.
Мы с вами свяжемся в формате онлайн конференции, пообщаемся в течение часа и я задам ряд вопросов:
◽️О вашей текущей ситуации в автоматизации HR
◽️О том, к чему стремитесь
◽️Какие есть задачи и сложности
◽️И прочие подобные вопросы
В подарок я проведу для вас консультацию продолжительностью 1 час, отвечу на интересующие вас вопросы по автоматизации управления персоналом и WebSoft HCM.
Если вам это интересно, пишите мне в комментариях под этим постом или по моим контактам:
✉️ mp@mpros.ru
@MikhailProtasov
Чек-лист проектирования отчета
1. Цель. Зачем нужен отчет: для контроля, планирования или анализа.
2. Выборка. Что попадет в отчет: сотрудники, заявки, учебные программы и т.д. Здесь можно задать критерии включения и исключения в выборку.
3. Фильтры. Как пользователь будет уточнять данные — по подразделению, периоду, наставнику и т.д.
4. Колонки и показатели. Какие поля и в каком порядке будут отображаться, как рассчитывать для них метрики.
5. Агрегация. Как будут подсчитываться итоги, средние значения, проценты.
6. Группировка. Если отчет сводный — по каким признакам он должен группироваться: филиал, руководитель, тип программы обучения и т.д.
7. Цветовое кодирование. Его удобно использовать для контрольных отчетов, чтобы быстро видеть отклонения данных от нормы.
8. Визуализация. Как представить отчет — в виде таблицы, диаграммы, дашборда.
9. Пагинация. Если записей планируется много, важно указать лимиты, чтобы отчет не перегружал систему.
Пример структуры отчета «Адаптация сотрудников»:
Цель: контроль адаптации и выявление проблемных точек.
Выборка: сотрудники в процессе адаптации на любом этапе.
Фильтры: подразделение, наставник, дата приема, длительность плана.
Показатели: ФИО, срок адаптации, количество выполненных задач, оценки, статус адаптации.
Агрегация: процент успешных адаптаций, среднее время обучения.
Группировка: тип программы, наставник.
Цветовое кодирование: зеленый — успешная адаптация, желтый — в процессе, красный — план не выполнен.
Визуализация: таблица.
📌 Такой отчет помогает визуализировать данные и принять решения на их основе.
+2
Выбираем способ реализации задач с учетом потребности заказчика
Заказчик спросил у меня, как настроить индивидуальные планы развития сотрудников.
В WebSoft HCM есть приложение - Управление индивидуальными планами развития. Но я не стал сразу говорить, что нужно именно оно. Сначала решил детальнее разобраться в потребностях.
В похожих ситуациях люди допускают ошибки:
1. Без анализа вариантов предлагают привычные инструменты. Хотя другие инструменты могут лучше подойти под конкретную задачу.
2. Предлагают инструмент на основе его названия. Но не факт, что этот инструмент направлен на актуальные для заказчика цели, даже если называется похоже.
3. Задают заказчику вопросы, не показывая варианты. Но если заказчик не видит примеры решений, ему обычно сложно детализировать задачу.
Я показал заказчику три инструмента:
1. Индивидуальный план развития, настроенный в стандартном приложении - скрин 1.
2. Модульную программу обучения - скрин 2.
3. Планы деятельности карьерных этапов - скрин 3.
Рассказал об их плюсах и минусах, практиках использования.
В итоге выбрали вариант 3, так как:
1. Определили, что в ближайшее время планы развития сотрудников заказчика будут типовыми.
2. В организации уже автоматизирована адаптация персонала. В ней используется похожий интерфейс. Значит, пользователям и администраторам будет удобнее работать с ним.
3. На основе выполнения этих планов будет планироваться карьерный рост.
Вывод: перед проектом изучайте различные инструменты, их плюсы, минусы, практику использования. Например, на моих курсах для аналитиков Websoft HCM.
Завтра провожу вебинар "Приложение Комплексная оценка персонала"
Уровень: базовый
🗓 01 апреля
🕑 11:00 мск
Ссылка
Целеполагание при проектировании отчетов
Существует три типа отчетов:
▪️Для контроля — все ли идет по плану или нужно скорректировать процесс.
Например: «Процент сотрудников, прошедших адаптацию вовремя».
▪️Для планирования и прогноза — что ждет компанию в дальнейшем и как распределить ресурсы.
Например: «Заявки на обучение». Этот отчет поможет оценить нагрузку и бюджет на обучение в следующем периоде.
▪️Для исследования — почему происходят события и как они взаимосвязаны.
Например: «Активность сотрудников в базе знаний в сравнении с производительностью».
➡️ При проектировании отчета важно ответить на вопрос: «Какое решение будет принимать пользователь отчета?»
Публикую актуальную таблицу с описанием всех моих учебных программ!
Если хотите записаться на обучение или есть какие-либо вопросы насчет него, пишите!
✉️ mp@mpros.ru
@MikhailProtasov
В среду провожу вебинар "Анализ производительности Websoft HCM"
Уровень: продвинутый
🗓 18 марта
🕑 11:00 мск
Ссылка
Готовлю карту типовых автоматизируемых HR процессов, их целей и направлений автоматизации!
Например:
Автоматизация адаптации
Цели:
- Уменьшение текучести персонала в первые месяцы работы
- Увеличение скорости выхода новичка на уровень опытного сотрудника
Направления автоматизации:
- Назначение плана адаптации сотрудникам
- Отображение плана адаптации
- Взаимодействие с наставниками
- Контроль движения по треку
- Завершение адаптации
- Формирование пула наставников
- Оценка наставников
Эти цели и направления буду связывать с нашими и другими кейсами в области Websoft HCM!
Проголосуйте в опросе ниже, что думаете насчет такой идеи.
Теперь мой канал доступен и в Max!
Подписывайтесь!
https://max.ru/id772578723603_biz
На следующей неделе в среду провожу вебинар "Настройка нестандартных отзывов на примере чек листа магазина"
Уровень: продвинутый
🗓 4 марта
🕑 11:00 мск
Ссылка
Функциональные требования и ТЗ: зачем их разделять
Иногда в дополнение к функциональным требованиям (ФТ) составляется техзадание (ТЗ).
▪️ Функциональные требования отвечают на вопрос что должна делать система. Здесь фиксируются потребности пользователей, ожидаемый результат и ограничения.
Например: «Сотрудник должен иметь возможность подать заявку на обучение и отслеживать ее статус».
▪️ ТЗ отвечает на вопрос какими инструментами это должно быть реализовано.
Например: «Для кеширования информации о заявках на согласовании будет создана новая кастомная таблица в БД с определенным набором атрибутов».
➡️ Функциональные требования составляет бизнес-аналитик, а ТЗ — системный аналитик.
Почему нельзя смешивать ТЗ и функциональные требования:
- Теряется понятность. HR-специалисту может быть сложно разбираться с технической терминологией.
- Путаются уровни ответственности. Неясно, кто должен согласовывать какие пункты.
✔️ Поэтому сначала нужно составить функциональные требования, затем — ТЗ, связанное с ФТ.
Функциональные требования и ТЗ: зачем их разделять
Иногда в дополнение к функциональным требованиям составляется техзадание (ТЗ).
▪️ Функциональные требования отвечают на вопрос что должна делать система. Здесь фиксируются потребности пользователей, ожидаемый результат и ограничения.
Например: «Сотрудник должен иметь возможность подать заявку на обучение и отслеживать ее статус».
▪️ ТЗ отвечает на вопрос какими инструментами это должно быть реализовано.
Например: «Для кеширования информации о заявках на согласовании будет создана новая кастомная таблица в БД с определенным набором атрибутов».
➡️ Функциональные требования составляет бизнес-аналитик а, а ТЗ — системный аналитик.
Почему нельзя смешивать ТЗ и функциональные требования:
- Теряется понятность. HR-специалисту сложно разбираться с алгоритмами, а разработчику — понимать цели компании.
- Путаются уровни ответственности. Неясно, кто должен согласовывать отдельные пункты — руководство компании или IT-департамент.
✔️ Поэтому сначала нужно составить функциональные требования, затем — ТЗ, а после — связать их ссылками.
Контрольные точки в управлении проектами
Если вы управляете проектом, я рекомендую определить промежуточные контрольные точки. В каждой из которых проводить ретроспективу: все ли идет нормально? Если возникли проблемы, то какие причины? Можно ли их устранить и как? Как скорректировать дальнейшие планы с учетом возникших изменений?
На наших проектах, связанных с Websoft HCM, мы обычно ставим эти контрольные точки с периодичностью от раза в неделю до раза в месяц.
Имеет смысл определить показатели для анализа на каждой контрольной точке. В нашем случае они такие:
▫️ Трудозатраты. Соответствуют плановым к текущему моменту или нет.
▫️ Сроки. Аналогично.
▫️ Стабильность. Как много возникает инцидентов с ранее разработанным функционалом. Особенно после очередного релиза.
▫️ Коммуникация. Заказчик с исполнителем в эмоциональном состоянии сотрудничества или борьбы? Часто ли кто-либо сообщает, что до него не дошла важная информация?
▫️ Прозрачность. Понимают ли все стороны на каком этапе находятся какие задачи.
▫️ Цели. Насколько мы приблизились к достижению поставленных перед проектом целей? Есть ли смысл скорректировать цели?
Когда и как стоит писать функциональные требования для реализации системы
В прошлых постах я писал, что для начала работ по внедрению системы достаточно сценариев использования и реестра компонентов системы.
Напомню:
▪️Сценарии описывают действия пользователей в системе;
▪️Реестр содержит объекты, которые нужно создать или доработать.
Однако в некоторых случаях требуется больше информации — например, когда:
▪️ В процессах большое количество ролей, отчетов, вычислений;
▪️ Проект необходимо описать более подробно для согласования со стейкхолдерами.
В этих случаях можно дополнить документацию функциональными требованиями.
Возможная структура функциональных требований
▫️ Оглавление
▫️ Цели автоматизации
▫️ Термины
▫️ Описание ролей пользователей
▫️ Сценарии использования
▫️ Номер и название каждого требования
▫️ Описание каждого требования
▫️ Описание и макеты интерфейсов
▫️ Алгоритмы определения значений ключевых переменных
▫️ Требования к отчетности
▫️ Ориентировочное количество пользователей
➡️ Следите, чтобы функциональные требования не были слишком объемными — так их сложнее будет прочитать, согласовать и полностью реализовать.
Автоматизацию каких HR процессов нам чаще всего заказывают
Наши текущие проекты в работе (не считая обучения и консультаций):
▫️ Оценка компетенций - 3 проекта
▫️ Редизайн портала - 3 проекта
▫️ Интеграция с внешними системами - 3 проекта
▫️ Адаптация новых сотрудников - 1 проект
▫️ Геймификация - 1 проект
В целом это отражает наиболее частые направления кастомизаций при использовании Websoft HCM. Возможно, кроме геймификации, она не так востребована, как прочее из этого списка.
На следующей неделе в среду провожу вебинар "Настройка отзывов"
Уровень: продвинутый
🗓 18 февраля
🕑 11:00 мск
Ссылка
اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
