На следующей неделе в среду провожу вебинар "Настраиваемые поля и типы данных объектов"
Уровень: продвинутый
🗓 21 января
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 21 января
🕑 11:00 мск
Ссылка
👍6🔥5
От сценариев — к системному анализу
Следующий этап после написания сценариев использования — системный анализ. Он позволяет определить, какие инструменты будут использованы для каждого сценария.
Приведем пример.
✔️ Этап сценария: «Сотрудник получает уведомление о необходимости планирования отпуска»
✔️ Для этого необходимо:
- создать агент;
- составить шаблон уведомления;
- создать тип уведомления.
Так формируется реестр компонентов — список объектов, которые нужно создать или настроить (агенты, шаблоны, выборки и т.д.).
➡️ Эту работу обычно выполняет системный аналитик. Он связывает бизнес-логику, описанную в сценариях, с технической реализацией.
➡️ Цель системного анализа — превратить сценарии в конкретный набор объектов и настроек системы. Так разработчики поймут, какие инструменты нужно задействовать для внедрения системы в соответствии с пожеланиями заказчика.
Следующий этап после написания сценариев использования — системный анализ. Он позволяет определить, какие инструменты будут использованы для каждого сценария.
Приведем пример.
✔️ Этап сценария: «Сотрудник получает уведомление о необходимости планирования отпуска»
✔️ Для этого необходимо:
- создать агент;
- составить шаблон уведомления;
- создать тип уведомления.
Так формируется реестр компонентов — список объектов, которые нужно создать или настроить (агенты, шаблоны, выборки и т.д.).
➡️ Эту работу обычно выполняет системный аналитик. Он связывает бизнес-логику, описанную в сценариях, с технической реализацией.
➡️ Цель системного анализа — превратить сценарии в конкретный набор объектов и настроек системы. Так разработчики поймут, какие инструменты нужно задействовать для внедрения системы в соответствии с пожеланиями заказчика.
👍5🔥2❤1
👍10🔥2
Как составить реестр компонентов
Когда сценарии использования готовы, следующий шаг — определить, через какие инструменты системы реализуются желаемые возможности. Для этого создается реестр компонентов — документ, который связывает логику процессов со структурой платформы.
Как строится реестр компонентов:
Например, это может быть таблица с данными:
1. Сам компонент системы — конкретный объект: агент, форма, шаблон уведомления, отчет.
2. Сценарий — в каком этапе он участвует.
3. Назначение — что этот компонент делает: отправляет уведомление, записывает данные, считает показатели.
4. Ответственный — кто создает или настраивает компонент.
5. Статус — создан, доработан, на проверке, внедрен.
Зачем нужен реестр компонентов
✔️ Позволяет оценить весь объем работ и контролировать их выполнение.
✔️ Помогает команде изучить, какие инструменты уже есть в системе, а какие нужно разработать.
✔️ Снижает риск дублирования компонентов и их задач.
▪️ Компоненты нужно описывать в связке со сценариями, а также регулярно обновлять реестр при необходимости.
Когда сценарии использования готовы, следующий шаг — определить, через какие инструменты системы реализуются желаемые возможности. Для этого создается реестр компонентов — документ, который связывает логику процессов со структурой платформы.
Как строится реестр компонентов:
Например, это может быть таблица с данными:
1. Сам компонент системы — конкретный объект: агент, форма, шаблон уведомления, отчет.
2. Сценарий — в каком этапе он участвует.
3. Назначение — что этот компонент делает: отправляет уведомление, записывает данные, считает показатели.
4. Ответственный — кто создает или настраивает компонент.
5. Статус — создан, доработан, на проверке, внедрен.
Зачем нужен реестр компонентов
✔️ Позволяет оценить весь объем работ и контролировать их выполнение.
✔️ Помогает команде изучить, какие инструменты уже есть в системе, а какие нужно разработать.
✔️ Снижает риск дублирования компонентов и их задач.
▪️ Компоненты нужно описывать в связке со сценариями, а также регулярно обновлять реестр при необходимости.
👍8
На следующей неделе в среду провожу вебинар "Настройка отзывов"
Уровень: продвинутый
🗓 18 февраля
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 18 февраля
🕑 11:00 мск
Ссылка
👍8
Автоматизацию каких HR процессов нам чаще всего заказывают
Наши текущие проекты в работе (не считая обучения и консультаций):
▫️ Оценка компетенций - 3 проекта
▫️ Редизайн портала - 3 проекта
▫️ Интеграция с внешними системами - 3 проекта
▫️ Адаптация новых сотрудников - 1 проект
▫️ Геймификация - 1 проект
В целом это отражает наиболее частые направления кастомизаций при использовании Websoft HCM. Возможно, кроме геймификации, она не так востребована, как прочее из этого списка.
Наши текущие проекты в работе (не считая обучения и консультаций):
▫️ Оценка компетенций - 3 проекта
▫️ Редизайн портала - 3 проекта
▫️ Интеграция с внешними системами - 3 проекта
▫️ Адаптация новых сотрудников - 1 проект
▫️ Геймификация - 1 проект
В целом это отражает наиболее частые направления кастомизаций при использовании Websoft HCM. Возможно, кроме геймификации, она не так востребована, как прочее из этого списка.
👍6
Когда и как стоит писать функциональные требования для реализации системы
В прошлых постах я писал, что для начала работ по внедрению системы достаточно сценариев использования и реестра компонентов системы.
Напомню:
▪️Сценарии описывают действия пользователей в системе;
▪️Реестр содержит объекты, которые нужно создать или доработать.
Однако в некоторых случаях требуется больше информации — например, когда:
▪️ В процессах большое количество ролей, отчетов, вычислений;
▪️ Проект необходимо описать более подробно для согласования со стейкхолдерами.
В этих случаях можно дополнить документацию функциональными требованиями.
Возможная структура функциональных требований
▫️ Оглавление
▫️ Цели автоматизации
▫️ Термины
▫️ Описание ролей пользователей
▫️ Сценарии использования
▫️ Номер и название каждого требования
▫️ Описание каждого требования
▫️ Описание и макеты интерфейсов
▫️ Алгоритмы определения значений ключевых переменных
▫️ Требования к отчетности
▫️ Ориентировочное количество пользователей
➡️ Следите, чтобы функциональные требования не были слишком объемными — так их сложнее будет прочитать, согласовать и полностью реализовать.
В прошлых постах я писал, что для начала работ по внедрению системы достаточно сценариев использования и реестра компонентов системы.
Напомню:
▪️Сценарии описывают действия пользователей в системе;
▪️Реестр содержит объекты, которые нужно создать или доработать.
Однако в некоторых случаях требуется больше информации — например, когда:
▪️ В процессах большое количество ролей, отчетов, вычислений;
▪️ Проект необходимо описать более подробно для согласования со стейкхолдерами.
В этих случаях можно дополнить документацию функциональными требованиями.
Возможная структура функциональных требований
▫️ Оглавление
▫️ Цели автоматизации
▫️ Термины
▫️ Описание ролей пользователей
▫️ Сценарии использования
▫️ Номер и название каждого требования
▫️ Описание каждого требования
▫️ Описание и макеты интерфейсов
▫️ Алгоритмы определения значений ключевых переменных
▫️ Требования к отчетности
▫️ Ориентировочное количество пользователей
➡️ Следите, чтобы функциональные требования не были слишком объемными — так их сложнее будет прочитать, согласовать и полностью реализовать.
👍6🔥2
Контрольные точки в управлении проектами
Если вы управляете проектом, я рекомендую определить промежуточные контрольные точки. В каждой из которых проводить ретроспективу: все ли идет нормально? Если возникли проблемы, то какие причины? Можно ли их устранить и как? Как скорректировать дальнейшие планы с учетом возникших изменений?
На наших проектах, связанных с Websoft HCM, мы обычно ставим эти контрольные точки с периодичностью от раза в неделю до раза в месяц.
Имеет смысл определить показатели для анализа на каждой контрольной точке. В нашем случае они такие:
▫️ Трудозатраты. Соответствуют плановым к текущему моменту или нет.
▫️ Сроки. Аналогично.
▫️ Стабильность. Как много возникает инцидентов с ранее разработанным функционалом. Особенно после очередного релиза.
▫️ Коммуникация. Заказчик с исполнителем в эмоциональном состоянии сотрудничества или борьбы? Часто ли кто-либо сообщает, что до него не дошла важная информация?
▫️ Прозрачность. Понимают ли все стороны на каком этапе находятся какие задачи.
▫️ Цели. Насколько мы приблизились к достижению поставленных перед проектом целей? Есть ли смысл скорректировать цели?
Если вы управляете проектом, я рекомендую определить промежуточные контрольные точки. В каждой из которых проводить ретроспективу: все ли идет нормально? Если возникли проблемы, то какие причины? Можно ли их устранить и как? Как скорректировать дальнейшие планы с учетом возникших изменений?
На наших проектах, связанных с Websoft HCM, мы обычно ставим эти контрольные точки с периодичностью от раза в неделю до раза в месяц.
Имеет смысл определить показатели для анализа на каждой контрольной точке. В нашем случае они такие:
▫️ Трудозатраты. Соответствуют плановым к текущему моменту или нет.
▫️ Сроки. Аналогично.
▫️ Стабильность. Как много возникает инцидентов с ранее разработанным функционалом. Особенно после очередного релиза.
▫️ Коммуникация. Заказчик с исполнителем в эмоциональном состоянии сотрудничества или борьбы? Часто ли кто-либо сообщает, что до него не дошла важная информация?
▫️ Прозрачность. Понимают ли все стороны на каком этапе находятся какие задачи.
▫️ Цели. Насколько мы приблизились к достижению поставленных перед проектом целей? Есть ли смысл скорректировать цели?
🔥4❤2
Функциональные требования и ТЗ: зачем их разделять
Иногда в дополнение к функциональным требованиям (ФТ) составляется техзадание (ТЗ).
▪️ Функциональные требования отвечают на вопрос что должна делать система. Здесь фиксируются потребности пользователей, ожидаемый результат и ограничения.
Например: «Сотрудник должен иметь возможность подать заявку на обучение и отслеживать ее статус».
▪️ ТЗ отвечает на вопрос какими инструментами это должно быть реализовано.
Например: «Для кеширования информации о заявках на согласовании будет создана новая кастомная таблица в БД с определенным набором атрибутов».
➡️ Функциональные требования составляет бизнес-аналитик, а ТЗ — системный аналитик.
Почему нельзя смешивать ТЗ и функциональные требования:
- Теряется понятность. HR-специалисту может быть сложно разбираться с технической терминологией.
- Путаются уровни ответственности. Неясно, кто должен согласовывать какие пункты.
✔️ Поэтому сначала нужно составить функциональные требования, затем — ТЗ, связанное с ФТ.
Иногда в дополнение к функциональным требованиям (ФТ) составляется техзадание (ТЗ).
▪️ Функциональные требования отвечают на вопрос что должна делать система. Здесь фиксируются потребности пользователей, ожидаемый результат и ограничения.
Например: «Сотрудник должен иметь возможность подать заявку на обучение и отслеживать ее статус».
▪️ ТЗ отвечает на вопрос какими инструментами это должно быть реализовано.
Например: «Для кеширования информации о заявках на согласовании будет создана новая кастомная таблица в БД с определенным набором атрибутов».
➡️ Функциональные требования составляет бизнес-аналитик, а ТЗ — системный аналитик.
Почему нельзя смешивать ТЗ и функциональные требования:
- Теряется понятность. HR-специалисту может быть сложно разбираться с технической терминологией.
- Путаются уровни ответственности. Неясно, кто должен согласовывать какие пункты.
✔️ Поэтому сначала нужно составить функциональные требования, затем — ТЗ, связанное с ФТ.
👍9🔥3❤1
На следующей неделе в среду провожу вебинар "Настройка нестандартных отзывов на примере чек листа магазина"
Уровень: продвинутый
🗓 4 марта
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 4 марта
🕑 11:00 мск
Ссылка
👍5
👍8
Готовлю карту типовых автоматизируемых HR процессов, их целей и направлений автоматизации!
Например:
Автоматизация адаптации
Цели:
- Уменьшение текучести персонала в первые месяцы работы
- Увеличение скорости выхода новичка на уровень опытного сотрудника
Направления автоматизации:
- Назначение плана адаптации сотрудникам
- Отображение плана адаптации
- Взаимодействие с наставниками
- Контроль движения по треку
- Завершение адаптации
- Формирование пула наставников
- Оценка наставников
Эти цели и направления автоматизации буду связывать с нашими и другими кейсами в области Websoft HCM!
Проголосуйте в опросе ниже, что думаете насчет такой идеи.
Например:
Автоматизация адаптации
Цели:
- Уменьшение текучести персонала в первые месяцы работы
- Увеличение скорости выхода новичка на уровень опытного сотрудника
Направления автоматизации:
- Назначение плана адаптации сотрудникам
- Отображение плана адаптации
- Взаимодействие с наставниками
- Контроль движения по треку
- Завершение адаптации
- Формирование пула наставников
- Оценка наставников
Эти цели и направления автоматизации буду связывать с нашими и другими кейсами в области Websoft HCM!
Проголосуйте в опросе ниже, что думаете насчет такой идеи.
🔥7
Карта типовых автоматизируемых HR процессов (пример выше)
Anonymous Poll
76%
Очень полезно
15%
Есть некоторая польза
0%
Бесполезно
9%
Пока непонятно, нужно смотреть, что получится
В среду провожу вебинар "Анализ производительности Websoft HCM"
Уровень: продвинутый
🗓 18 марта
🕑 11:00 мск
Ссылка
Уровень: продвинутый
🗓 18 марта
🕑 11:00 мск
Ссылка
👍7🔥2
Программы_обучений_и_консультации_от_М_Про_Системс.xlsx
13.5 KB
Публикую актуальную таблицу с описанием всех моих учебных программ!
Если хотите записаться на обучение или есть какие-либо вопросы насчет него, пишите!
✉️ mp@mpros.ru
@MikhailProtasov
Если хотите записаться на обучение или есть какие-либо вопросы насчет него, пишите!
✉️ mp@mpros.ru
@MikhailProtasov
👍3
Целеполагание при проектировании отчетов
Существует три типа отчетов:
▪️Для контроля — все ли идет по плану или нужно скорректировать процесс.
Например: «Процент сотрудников, прошедших адаптацию вовремя».
▪️Для планирования и прогноза — что ждет компанию в дальнейшем и как распределить ресурсы.
Например: «Заявки на обучение». Этот отчет поможет оценить нагрузку и бюджет на обучение в следующем периоде.
▪️Для исследования — почему происходят события и как они взаимосвязаны.
Например: «Активность сотрудников в базе знаний в сравнении с производительностью».
➡️ При проектировании отчета важно ответить на вопрос: «Какое решение будет принимать пользователь отчета?»
Существует три типа отчетов:
▪️Для контроля — все ли идет по плану или нужно скорректировать процесс.
Например: «Процент сотрудников, прошедших адаптацию вовремя».
▪️Для планирования и прогноза — что ждет компанию в дальнейшем и как распределить ресурсы.
Например: «Заявки на обучение». Этот отчет поможет оценить нагрузку и бюджет на обучение в следующем периоде.
▪️Для исследования — почему происходят события и как они взаимосвязаны.
Например: «Активность сотрудников в базе знаний в сравнении с производительностью».
➡️ При проектировании отчета важно ответить на вопрос: «Какое решение будет принимать пользователь отчета?»
👍2
Завтра провожу вебинар "Приложение Комплексная оценка персонала"
Уровень: базовый
🗓 01 апреля
🕑 11:00 мск
Ссылка
Уровень: базовый
🗓 01 апреля
🕑 11:00 мск
Ссылка
👍7
Выбираем способ реализации задач с учетом потребности заказчика
Заказчик спросил у меня, как настроить индивидуальные планы развития сотрудников.
В WebSoft HCM есть приложение - Управление индивидуальными планами развития. Но я не стал сразу говорить, что нужно именно оно. Сначала решил детальнее разобраться в потребностях.
В похожих ситуациях люди допускают ошибки:
1. Без анализа вариантов предлагают привычные инструменты. Хотя другие инструменты могут лучше подойти под конкретную задачу.
2. Предлагают инструмент на основе его названия. Но не факт, что этот инструмент направлен на актуальные для заказчика цели, даже если называется похоже.
3. Задают заказчику вопросы, не показывая варианты. Но если заказчик не видит примеры решений, ему обычно сложно детализировать задачу.
Я показал заказчику три инструмента:
1. Индивидуальный план развития, настроенный в стандартном приложении - скрин 1.
2. Модульную программу обучения - скрин 2.
3. Планы деятельности карьерных этапов - скрин 3.
Рассказал об их плюсах и минусах, практиках использования.
В итоге выбрали вариант 3, так как:
1. Определили, что в ближайшее время планы развития сотрудников заказчика будут типовыми.
2. В организации уже автоматизирована адаптация персонала. В ней используется похожий интерфейс. Значит, пользователям и администраторам будет удобнее работать с ним.
3. На основе выполнения этих планов будет планироваться карьерный рост.
Вывод: перед проектом изучайте различные инструменты, их плюсы, минусы, практику использования. Например, на моих курсах для аналитиков Websoft HCM.
Заказчик спросил у меня, как настроить индивидуальные планы развития сотрудников.
В WebSoft HCM есть приложение - Управление индивидуальными планами развития. Но я не стал сразу говорить, что нужно именно оно. Сначала решил детальнее разобраться в потребностях.
В похожих ситуациях люди допускают ошибки:
1. Без анализа вариантов предлагают привычные инструменты. Хотя другие инструменты могут лучше подойти под конкретную задачу.
2. Предлагают инструмент на основе его названия. Но не факт, что этот инструмент направлен на актуальные для заказчика цели, даже если называется похоже.
3. Задают заказчику вопросы, не показывая варианты. Но если заказчик не видит примеры решений, ему обычно сложно детализировать задачу.
Я показал заказчику три инструмента:
1. Индивидуальный план развития, настроенный в стандартном приложении - скрин 1.
2. Модульную программу обучения - скрин 2.
3. Планы деятельности карьерных этапов - скрин 3.
Рассказал об их плюсах и минусах, практиках использования.
В итоге выбрали вариант 3, так как:
1. Определили, что в ближайшее время планы развития сотрудников заказчика будут типовыми.
2. В организации уже автоматизирована адаптация персонала. В ней используется похожий интерфейс. Значит, пользователям и администраторам будет удобнее работать с ним.
3. На основе выполнения этих планов будет планироваться карьерный рост.
Вывод: перед проектом изучайте различные инструменты, их плюсы, минусы, практику использования. Например, на моих курсах для аналитиков Websoft HCM.
👍6❤2