Автоматизируем управление персоналом
По вопросам заказа услуг обращайтесь:
mp@mpros.ru
@MikhailProtasov
mpros.ru
Post #384
318
Анонс курса по оценке персонала и поздравление с 1 апреля
- 😁 7
- 👍 2
- 🔥 2
Channel Public Channel
М М Про Системс
@mprosystems
- Subscribers
- 497
- Photos
- 24
- Videos
- 22
- Links
- 193
Showing posts older than #385 · Back to latest
Older Posts 20 shown
Post #383
324
Завтра провожу вебинар "Приложение Комплексная оценка персонала"
Уровень: базовый
🗓 01 апреля
🕑 11:00 мск
Ссылка
Уровень: базовый
🗓 01 апреля
🕑 11:00 мск
Ссылка
- 👍 7
Post #382
441
Целеполагание при проектировании отчетов
Существует три типа отчетов:
▪️Для контроля — все ли идет по плану или нужно скорректировать процесс.
Например: «Процент сотрудников, прошедших адаптацию вовремя».
▪️Для планирования и прогноза — что ждет компанию в дальнейшем и как распределить ресурсы.
Например: «Заявки на обучение». Этот отчет поможет оценить нагрузку и бюджет на обучение в следующем периоде.
▪️Для исследования — почему происходят события и как они взаимосвязаны.
Например: «Активность сотрудников в базе знаний в сравнении с производительностью».
➡️ При проектировании отчета важно ответить на вопрос: «Какое решение будет принимать пользователь отчета?»
Существует три типа отчетов:
▪️Для контроля — все ли идет по плану или нужно скорректировать процесс.
Например: «Процент сотрудников, прошедших адаптацию вовремя».
▪️Для планирования и прогноза — что ждет компанию в дальнейшем и как распределить ресурсы.
Например: «Заявки на обучение». Этот отчет поможет оценить нагрузку и бюджет на обучение в следующем периоде.
▪️Для исследования — почему происходят события и как они взаимосвязаны.
Например: «Активность сотрудников в базе знаний в сравнении с производительностью».
➡️ При проектировании отчета важно ответить на вопрос: «Какое решение будет принимать пользователь отчета?»
- 👍 2
Post #381
470
Программы_обучений_и_консультации_от_М_Про_Системс.xlsx13.5 KB
Публикую актуальную таблицу с описанием всех моих учебных программ!
Если хотите записаться на обучение или есть какие-либо вопросы насчет него, пишите!
✉️ mp@mpros.ru
@MikhailProtasov
Если хотите записаться на обучение или есть какие-либо вопросы насчет него, пишите!
✉️ mp@mpros.ru
@MikhailProtasov
- 👍 3
Post #380
518
В среду провожу вебинар "Анализ производительности Websoft HCM"
Уровень: продвинутый
🗓 18 марта
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 18 марта
🕑 11:00 мск
Ссылка
- 👍 7
- 🔥 2
Post #379
535
Post #378
472
Готовлю карту типовых автоматизируемых HR процессов, их целей и направлений автоматизации!
Например:
Автоматизация адаптации
Цели:
- Уменьшение текучести персонала в первые месяцы работы
- Увеличение скорости выхода новичка на уровень опытного сотрудника
Направления автоматизации:
- Назначение плана адаптации сотрудникам
- Отображение плана адаптации
- Взаимодействие с наставниками
- Контроль движения по треку
- Завершение адаптации
- Формирование пула наставников
- Оценка наставников
Эти цели и направления автоматизации буду связывать с нашими и другими кейсами в области Websoft HCM!
Проголосуйте в опросе ниже, что думаете насчет такой идеи.
Например:
Автоматизация адаптации
Цели:
- Уменьшение текучести персонала в первые месяцы работы
- Увеличение скорости выхода новичка на уровень опытного сотрудника
Направления автоматизации:
- Назначение плана адаптации сотрудникам
- Отображение плана адаптации
- Взаимодействие с наставниками
- Контроль движения по треку
- Завершение адаптации
- Формирование пула наставников
- Оценка наставников
Эти цели и направления автоматизации буду связывать с нашими и другими кейсами в области Websoft HCM!
Проголосуйте в опросе ниже, что думаете насчет такой идеи.
- 🔥 7
Post #377
466
- 👍 8
Post #376
586
На следующей неделе в среду провожу вебинар "Настройка нестандартных отзывов на примере чек листа магазина"
Уровень: продвинутый
🗓 4 марта
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 4 марта
🕑 11:00 мск
Ссылка
- 👍 5
Post #375
547
Функциональные требования и ТЗ: зачем их разделять
Иногда в дополнение к функциональным требованиям (ФТ) составляется техзадание (ТЗ).
▪️ Функциональные требования отвечают на вопрос что должна делать система. Здесь фиксируются потребности пользователей, ожидаемый результат и ограничения.
Например: «Сотрудник должен иметь возможность подать заявку на обучение и отслеживать ее статус».
▪️ ТЗ отвечает на вопрос какими инструментами это должно быть реализовано.
Например: «Для кеширования информации о заявках на согласовании будет создана новая кастомная таблица в БД с определенным набором атрибутов».
➡️ Функциональные требования составляет бизнес-аналитик, а ТЗ — системный аналитик.
Почему нельзя смешивать ТЗ и функциональные требования:
- Теряется понятность. HR-специалисту может быть сложно разбираться с технической терминологией.
- Путаются уровни ответственности. Неясно, кто должен согласовывать какие пункты.
✔️ Поэтому сначала нужно составить функциональные требования, затем — ТЗ, связанное с ФТ.
Иногда в дополнение к функциональным требованиям (ФТ) составляется техзадание (ТЗ).
▪️ Функциональные требования отвечают на вопрос что должна делать система. Здесь фиксируются потребности пользователей, ожидаемый результат и ограничения.
Например: «Сотрудник должен иметь возможность подать заявку на обучение и отслеживать ее статус».
▪️ ТЗ отвечает на вопрос какими инструментами это должно быть реализовано.
Например: «Для кеширования информации о заявках на согласовании будет создана новая кастомная таблица в БД с определенным набором атрибутов».
➡️ Функциональные требования составляет бизнес-аналитик, а ТЗ — системный аналитик.
Почему нельзя смешивать ТЗ и функциональные требования:
- Теряется понятность. HR-специалисту может быть сложно разбираться с технической терминологией.
- Путаются уровни ответственности. Неясно, кто должен согласовывать какие пункты.
✔️ Поэтому сначала нужно составить функциональные требования, затем — ТЗ, связанное с ФТ.
- 👍 9
- 🔥 3
- ❤ 1
Post #373
398
Контрольные точки в управлении проектами
Если вы управляете проектом, я рекомендую определить промежуточные контрольные точки. В каждой из которых проводить ретроспективу: все ли идет нормально? Если возникли проблемы, то какие причины? Можно ли их устранить и как? Как скорректировать дальнейшие планы с учетом возникших изменений?
На наших проектах, связанных с Websoft HCM, мы обычно ставим эти контрольные точки с периодичностью от раза в неделю до раза в месяц.
Имеет смысл определить показатели для анализа на каждой контрольной точке. В нашем случае они такие:
▫️ Трудозатраты. Соответствуют плановым к текущему моменту или нет.
▫️ Сроки. Аналогично.
▫️ Стабильность. Как много возникает инцидентов с ранее разработанным функционалом. Особенно после очередного релиза.
▫️ Коммуникация. Заказчик с исполнителем в эмоциональном состоянии сотрудничества или борьбы? Часто ли кто-либо сообщает, что до него не дошла важная информация?
▫️ Прозрачность. Понимают ли все стороны на каком этапе находятся какие задачи.
▫️ Цели. Насколько мы приблизились к достижению поставленных перед проектом целей? Есть ли смысл скорректировать цели?
Если вы управляете проектом, я рекомендую определить промежуточные контрольные точки. В каждой из которых проводить ретроспективу: все ли идет нормально? Если возникли проблемы, то какие причины? Можно ли их устранить и как? Как скорректировать дальнейшие планы с учетом возникших изменений?
На наших проектах, связанных с Websoft HCM, мы обычно ставим эти контрольные точки с периодичностью от раза в неделю до раза в месяц.
Имеет смысл определить показатели для анализа на каждой контрольной точке. В нашем случае они такие:
▫️ Трудозатраты. Соответствуют плановым к текущему моменту или нет.
▫️ Сроки. Аналогично.
▫️ Стабильность. Как много возникает инцидентов с ранее разработанным функционалом. Особенно после очередного релиза.
▫️ Коммуникация. Заказчик с исполнителем в эмоциональном состоянии сотрудничества или борьбы? Часто ли кто-либо сообщает, что до него не дошла важная информация?
▫️ Прозрачность. Понимают ли все стороны на каком этапе находятся какие задачи.
▫️ Цели. Насколько мы приблизились к достижению поставленных перед проектом целей? Есть ли смысл скорректировать цели?
- 🔥 4
- ❤ 2
Post #372
399
Когда и как стоит писать функциональные требования для реализации системы
В прошлых постах я писал, что для начала работ по внедрению системы достаточно сценариев использования и реестра компонентов системы.
Напомню:
▪️Сценарии описывают действия пользователей в системе;
▪️Реестр содержит объекты, которые нужно создать или доработать.
Однако в некоторых случаях требуется больше информации — например, когда:
▪️ В процессах большое количество ролей, отчетов, вычислений;
▪️ Проект необходимо описать более подробно для согласования со стейкхолдерами.
В этих случаях можно дополнить документацию функциональными требованиями.
Возможная структура функциональных требований
▫️ Оглавление
▫️ Цели автоматизации
▫️ Термины
▫️ Описание ролей пользователей
▫️ Сценарии использования
▫️ Номер и название каждого требования
▫️ Описание каждого требования
▫️ Описание и макеты интерфейсов
▫️ Алгоритмы определения значений ключевых переменных
▫️ Требования к отчетности
▫️ Ориентировочное количество пользователей
➡️ Следите, чтобы функциональные требования не были слишком объемными — так их сложнее будет прочитать, согласовать и полностью реализовать.
В прошлых постах я писал, что для начала работ по внедрению системы достаточно сценариев использования и реестра компонентов системы.
Напомню:
▪️Сценарии описывают действия пользователей в системе;
▪️Реестр содержит объекты, которые нужно создать или доработать.
Однако в некоторых случаях требуется больше информации — например, когда:
▪️ В процессах большое количество ролей, отчетов, вычислений;
▪️ Проект необходимо описать более подробно для согласования со стейкхолдерами.
В этих случаях можно дополнить документацию функциональными требованиями.
Возможная структура функциональных требований
▫️ Оглавление
▫️ Цели автоматизации
▫️ Термины
▫️ Описание ролей пользователей
▫️ Сценарии использования
▫️ Номер и название каждого требования
▫️ Описание каждого требования
▫️ Описание и макеты интерфейсов
▫️ Алгоритмы определения значений ключевых переменных
▫️ Требования к отчетности
▫️ Ориентировочное количество пользователей
➡️ Следите, чтобы функциональные требования не были слишком объемными — так их сложнее будет прочитать, согласовать и полностью реализовать.
- 👍 6
- 🔥 2
Post #371
389
Post #370
437
Автоматизацию каких HR процессов нам чаще всего заказывают
Наши текущие проекты в работе (не считая обучения и консультаций):
▫️ Оценка компетенций - 3 проекта
▫️ Редизайн портала - 3 проекта
▫️ Интеграция с внешними системами - 3 проекта
▫️ Адаптация новых сотрудников - 1 проект
▫️ Геймификация - 1 проект
В целом это отражает наиболее частые направления кастомизаций при использовании Websoft HCM. Возможно, кроме геймификации, она не так востребована, как прочее из этого списка.
Наши текущие проекты в работе (не считая обучения и консультаций):
▫️ Оценка компетенций - 3 проекта
▫️ Редизайн портала - 3 проекта
▫️ Интеграция с внешними системами - 3 проекта
▫️ Адаптация новых сотрудников - 1 проект
▫️ Геймификация - 1 проект
В целом это отражает наиболее частые направления кастомизаций при использовании Websoft HCM. Возможно, кроме геймификации, она не так востребована, как прочее из этого списка.
- 👍 6
Post #369
425
На следующей неделе в среду провожу вебинар "Настройка отзывов"
Уровень: продвинутый
🗓 18 февраля
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 18 февраля
🕑 11:00 мск
Ссылка
- 👍 8
Post #368
596
Как составить реестр компонентов
Когда сценарии использования готовы, следующий шаг — определить, через какие инструменты системы реализуются желаемые возможности. Для этого создается реестр компонентов — документ, который связывает логику процессов со структурой платформы.
Как строится реестр компонентов:
Например, это может быть таблица с данными:
1. Сам компонент системы — конкретный объект: агент, форма, шаблон уведомления, отчет.
2. Сценарий — в каком этапе он участвует.
3. Назначение — что этот компонент делает: отправляет уведомление, записывает данные, считает показатели.
4. Ответственный — кто создает или настраивает компонент.
5. Статус — создан, доработан, на проверке, внедрен.
Зачем нужен реестр компонентов
✔️ Позволяет оценить весь объем работ и контролировать их выполнение.
✔️ Помогает команде изучить, какие инструменты уже есть в системе, а какие нужно разработать.
✔️ Снижает риск дублирования компонентов и их задач.
▪️ Компоненты нужно описывать в связке со сценариями, а также регулярно обновлять реестр при необходимости.
Когда сценарии использования готовы, следующий шаг — определить, через какие инструменты системы реализуются желаемые возможности. Для этого создается реестр компонентов — документ, который связывает логику процессов со структурой платформы.
Как строится реестр компонентов:
Например, это может быть таблица с данными:
1. Сам компонент системы — конкретный объект: агент, форма, шаблон уведомления, отчет.
2. Сценарий — в каком этапе он участвует.
3. Назначение — что этот компонент делает: отправляет уведомление, записывает данные, считает показатели.
4. Ответственный — кто создает или настраивает компонент.
5. Статус — создан, доработан, на проверке, внедрен.
Зачем нужен реестр компонентов
✔️ Позволяет оценить весь объем работ и контролировать их выполнение.
✔️ Помогает команде изучить, какие инструменты уже есть в системе, а какие нужно разработать.
✔️ Снижает риск дублирования компонентов и их задач.
▪️ Компоненты нужно описывать в связке со сценариями, а также регулярно обновлять реестр при необходимости.
- 👍 8
Post #367
487
- 👍 10
- 🔥 2
Post #366
628
От сценариев — к системному анализу
Следующий этап после написания сценариев использования — системный анализ. Он позволяет определить, какие инструменты будут использованы для каждого сценария.
Приведем пример.
✔️ Этап сценария: «Сотрудник получает уведомление о необходимости планирования отпуска»
✔️ Для этого необходимо:
- создать агент;
- составить шаблон уведомления;
- создать тип уведомления.
Так формируется реестр компонентов — список объектов, которые нужно создать или настроить (агенты, шаблоны, выборки и т.д.).
➡️ Эту работу обычно выполняет системный аналитик. Он связывает бизнес-логику, описанную в сценариях, с технической реализацией.
➡️ Цель системного анализа — превратить сценарии в конкретный набор объектов и настроек системы. Так разработчики поймут, какие инструменты нужно задействовать для внедрения системы в соответствии с пожеланиями заказчика.
Следующий этап после написания сценариев использования — системный анализ. Он позволяет определить, какие инструменты будут использованы для каждого сценария.
Приведем пример.
✔️ Этап сценария: «Сотрудник получает уведомление о необходимости планирования отпуска»
✔️ Для этого необходимо:
- создать агент;
- составить шаблон уведомления;
- создать тип уведомления.
Так формируется реестр компонентов — список объектов, которые нужно создать или настроить (агенты, шаблоны, выборки и т.д.).
➡️ Эту работу обычно выполняет системный аналитик. Он связывает бизнес-логику, описанную в сценариях, с технической реализацией.
➡️ Цель системного анализа — превратить сценарии в конкретный набор объектов и настроек системы. Так разработчики поймут, какие инструменты нужно задействовать для внедрения системы в соответствии с пожеланиями заказчика.
- 👍 5
- 🔥 2
- ❤ 1
Post #365
590
Forwarded from Михаил Протасов
This post (sticker, poll or similar) has no web preview. Open in Telegram
- 😁 14
- 👍 9
- 🔥 4
Post #364
584
На следующей неделе в среду провожу вебинар "Настраиваемые поля и типы данных объектов"
Уровень: продвинутый
🗓 21 января
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 21 января
🕑 11:00 мск
Ссылка
- 👍 6
- 🔥 5