Содержание


Модернизация RCM-центра (Resource and Capacity Management) на основе методики CBM-SOMA

Пример реализации

Comments

Resource and Capacity Management (RCM) – это название центра IBM, отвечающего за планирование, мониторинг и управление в области трудовых ресурсов, а также за наем этих ресурсов. Этот центр удовлетворяет ресурсные потребности бизнес-подразделений IBM за счет доступных внутренних ресурсов либо, если имеющиеся внутренние ресурсы недоступны или отсутствуют, RCM-центр инициирует мероприятия по внешнему найму специалистов через отдел управления персоналом. Центр выполняет мероприятия по краткосрочному и долгосрочному планированию ресурсов, а также помогает справляться с непредвиденными колебаниями потребностей в различных бизнес-подразделениях и удовлетворять эти потребности с целью сглаживания операций по внешнему найму в службе управления персоналом посредством контролируемых процессов найма. Центр ведет постоянную работу по минимизации разрыва между предложением и потребностями.

Центр имеет пять источников ресурсов для удовлетворения потребностей всех бизнес-подразделений. К числу этих источников относятся следующие каналы: ротация, высвобождение, кадровый резерв, наем, SSP (подрядчики IBM) и наем выпускников. В свою очередь, потребности генерируются следующими тремя источниками: 1) действующие контрактные обязательства по выполняемым проектам; 2) обязательства по новым проектам; 3) потребность в пополнении ресурсов. Потребность в пополнении – необходимость занятия определенных должностей в проектах вместо выбывших кандидатов.

Центр имеет хорошо отработанные рабочие процедуры и регулярно осуществляет контролируемые бизнес-процессы в интересах выполнения своих повседневных операций. Важнейшими из этих процессов являются следующие процессы в области трудовых ресурсов: планирование возможностей, исполнение, наем, ротация, управление кадровым резервом, SSP-операции и наем выпускников. Для выполнения этих процессов описываемый центр применяет такие глобальные стратегические инструменты IBM, как PMP (Professional Marketplace), GOM (Global Opportunity Marketplace), PD и Project DB, а также инструменты на базе Lotus Notes и Microsoft ® Excel.

Для преобразования бизнес-процессов в соответствующие ИТ-процессы применяется методика CBM-SOMA от IBM. Предлагаемая этой методикой многоуровневая архитектурная модель предприятия на основе SOA-решений используется для представления корпоративной архитектуры RCM-центра в виде соответствующей модели. В предлагаемой статье подробно рассматривается каждый сегмент архитектурной модели предприятия. Кроме того, производится оптимизация существующих бизнес-процессов и формирование ИТ-решения. В процессе написания данной статьи было проведено несколько семинаров с участием владельцев процессов, в ходе которых было достигнуто понимание имеющихся процессов, документированы текущие проблемы в таких областях, как существующие процессы и применяемые инструменты, а также предложены логические и физические модели будущих процессов.

Рисунок 1. Потребности – представление RCM-центра с точки зрения предложения
A Demand a supply view of RCM center
A Demand a supply view of RCM center

RCM-центр – карта CBM-компонентов

Рисунок 2. «Горячие» CBM-компоненты RCM-центра
RCM center CBM hot components
RCM center CBM hot components

Описание бизнес-компонентов

Стратегии и планирование предложения. Операции, выполняемые под руководством глобального сервисного центра IBM в Индии (GDC IBM India), отличаются значительной масштабностью (что характерно для данного географического региона), поэтому компонент «Стратегии и планирование предложения ресурсов» весьма важен. Этот компонент отвечает за построение стратегий по найму ресурсов в краткосрочной и долгосрочной перспективе и, соответственно, за подготовку планов реализации этих стратегий найма. Этот компонент заботится о бизнес-приоритетах и стратегиях организации на глобальном уровне.

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

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

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

Администрирование ресурсов. Данный компонент гарантирует наличие в соответствующих репозитариях корректной информации о ресурсах (JRSS, набор навыков, резюме, DOJ и т.д.). Это облегчает вступительные беседы менеджеров с нанимаемыми трудовыми ресурсами. Кроме того, этот компонент отвечает за ведение послужного списка специалиста, а также за учет отпусков и периодов длительного отсутствия.

Распределение и отслеживание ресурсов. Данный компонент связывает предложение ресурсов от всех имеющихся каналов (высвобождение, ротация, кадровый резерв, наем и SSP-операции) с потребностями различных проектов в ресурсах. Кроме того, он отслеживает конечные даты задействования трудовых ресурсов в проектах, а также ресурсы для удовлетворения ротационных потребностей проектов и ресурсы кадрового резерва. Этот компонент призван эффективно обеспечивать целевые показатели удовлетворения потребностей организации в трудовых ресурсах.

Наем трудовых ресурсов. Данный компонент действует как посредник, упрощающий взаимодействие RCM-центра с группой комплектования персонала (эскалация, наем для конкретных проектов и вербовочные мероприятия). Он отвечает за найм надлежащего специалиста для надлежащего удовлетворения имеющейся потребности в нужное время. Это компонент формирует «конвейер найма», демпфирующий колебания потребностей. Он принимает решения на основе конверсионных коэффициентов найма сотрудников.

Наем выпускников. Данный компонент управляет наймом выпускников и специалистов с опытом работы менее 12 месяцев. Он формирует предложение посредством предоставления сотрудникам этой категории необходимых возможностей для подготовки к работе на новом месте. Он осуществляет найм выпускников в конкретные проекты на периоды скрытого («теневого») участия и на периоды реального участия. Этот компонент планирует такие показатели, как количество привлекаемых специалистов и их категории, а также учебные заведения/нынешние компании претендентов.

SSP-операции. Данный компонент управляет наймом и расстановкой персонала в интересах субподрядчиков (SSP). Кроме того, он управляет отношениями с поставщиками в таких областях, как стратегии, наборы квалификационных навыков, перспективы и т.д. Он занимается распределением SSP-кандидатов посредством таких механизмов, как анализ резюме, беседы с кандидатами, прием на работу, увольнение/повторный прием и т.д.

Бизнес-анализ. Результаты работы этого компонента позволяют измерить продуктивность, стимулировать определенное поведение RCM-центра и обеспечить предложение. Этот компонент генерирует специальные отчеты, помогающие выявлять проблемы и находить способы их решения. Некоторые из инструментов этого компонента помогают повысить продуктивность RCM-центра. Они осуществляют анализ в интересах прогнозирования, заблаговременного выявления проблем и автоматизации повторяющихся ручных процедур.

В схеме на рис. 2 красным цветом обозначены т.н. «горячие» компоненты RCM-центра, которые подлежат бизнес-преобразованиям в первую очередь. Желтым цветом обозначены «потенциально горячие» компоненты, которые подлежат бизнес-преобразованиям во вторую очередь.

Текущие проблемы

Исполнение

  • Продолжительность цикла планирования ресурсов превышает один месяц. Это трудоемкий ручной процесс, замедляющий принятие решений различными заинтересованными сторонами и, соответственно, генерирующий неточный план возможностей, не учитывающий последние изменения в области потребностей и предложения.
  • План исполнения имеет недостаточную точность вследствие повседневных изменений потребностей и предложения.
  • SSP-процессы функционируют изолированно, без обратной связи с имеющимися системами исполнения и найма.
  • Все это приводит к потере дохода вследствие несвоевременного представления ресурсов для удовлетворения потребностей.
  • Необходимо уменьшить объем работы, выполняемой исполнительным персоналом RCM-центра (менеджеры по обеспечению компетенций, менеджеры по обслуживанию практических областей, менеджеры по ресурсам, менеджеры по подбору и расстановке кадров и т.д.).
  • Необходимо ослабить проблемы, обуславливаемые отсутствием полных спецификаций и необходимостью валидации имеющихся спецификаций, а также сократить затраты времени на исполнение.

Наем

  • В настоящее время генерация заявок по найму является трудозатратным процессом; отсутствует рационализированный совместный или единый поток работ с участием различных заинтересованных сторон.
  • В настоящее время в рассматриваемом RCM-центре службы найма трудовых ресурсов и службы управления персоналом функционируют независимо друг от друга, как большие изолированные зоны. Все взаимодействие между этими двумя подразделениями происходит в ручном режиме, а обмен информацией осуществляется посредством таблиц Excel.
  • Имеют место трудности при предоставлении корректных сведений по найму с детальными подробностями по JRSS в группу кадрового обеспечения подразделения управления персоналом.
  • В настоящее время генерация кодов о служебном положении для новых сотрудников представляет собой ручной процесс, выполняемый группой из четырех специалистов.
  • Необходимо оптимизировать составление текущих запросов по найму посредством отображения и обновления предыдущих запросов.
  • Все подпроцессы найма выполняются в ручном режиме.

Архитектура бизнес-решений для моделей будущих процессов

Система исполнения

  • Нынешний процесс планирования возможностей в области трудовых ресурсов основан на восходящем подходе, при котором необходимость найма выявляется после исчерпания внутренних ресурсов. Предлагаемая модернизация основана на нисходящем подходе, при котором наем управляется преимущественно планом предложения, основанным на результатах анализа.
  • Нынешний процесс планирования возможностей подлежит удалению из перечня операций RCM-центра.
  • Процесс валидации потребностей посредством PAL выведен за пределы процесса исполнения RCM-центра, вследствие чего задержки валидации потребностей больше не будут влиять на этот процесс. Потребности, прошедшие валидацию, поступают на вход процесса исполнения. Другими словами, реализация представляет собой восходящий процесс.
  • Выбор решения и подготовка плана исполнения осуществляется только для тех потребностей, которые необходимо удовлетворить не позднее ближайших 45 суток.
  • Нынешнее решение для исполнения учитывает не только внутренние ресурсы, доступные по различным каналам, но и текущие запросы по найму, которые в интересах планирования исполнения находятся в одном «конвейере» с внешним наймом.
  • Подлежат рассмотрению следующие внешние ресурсы для плана исполнения: IBM Regular ANOB (кандидаты на работу в IBM на постоянной основе), SSP ANOB (кандидаты на работу в SSP), кандидаты, выбранные с помощью Tech Select и PDM.
  • Запрос по найму в глобальный инструмент PMP генерируется только в том случае, если все внутренние ресурсы и существующие запросы по найму, основанные на плане предложения, не в состоянии удовлетворить соответствующую потребность. На практике этот тип запросов по найму составляет не более 3 – 4% от всех запросов по найму.
  • Для каждой потребности предоставляется DPI-индикатор приоритетности на основе атрибутов, документированных в бизнес-правилах.
  • Прекращается применение концепции месячного или недельного плана исполнения, подготавливаемого на еженедельной основе. Планирование становится повседневным непрерывным процессом, который в рамках 45-суточного окна обеспечивает предоставление решений для требований, генерируемых инкрементно на ежедневной основе.

Система найма

  • В рекомендованном нисходящем подходе руководители CFE/SFE, SLC и RCM сопровождают план предложения с целью его преобразования в план найма.
  • Логическое распределение ресурсов от внешних каналов найма к PA/к сектору/между секторами происходит непосредственно в процессе выбора решения.
  • Логическое распределение действует (в соответствии с физическим распределением ресурсов) до тех пор, пока не изменятся потребности, и вплоть до окончательного принятия кандидата.
  • Распределение кандидатов осуществляется согласно бизнес-правилам распределения по DPI-индикатору, изложенным в соответствующем документе. Этот процесс охватывает кандидатов, логическое распределение которых было нарушено или логическое распределение которых еще предстоит осуществить на стадии ANOB.
  • Задачи утверждения предложений и исключений, выполняемые руководителями CFE/SFE, SLC и RCM, теперь включены в сферу модернизации процесса найма.
  • Преобразование плана предложения связано с планом запросов по найму посредством следующих внутренних факторов.
    • Статистика регистрации потребностей
    • Наличие схожего набора навыков в кадровом резерве
    • o Специальные требования руководителей подразделений CFE/SFE и SLC

Архитектура ИТ-решения

Система исполнения

  • В настоящее время операции RCM-центра обеспечиваются хранилищами данных на основе таблиц Excel. Это снижает продуктивность персонала RCM-центра вследствие «зависаний» вычислительной системы при обработке больших объемов данных, открытых в таблицах Excel на настольном компьютере или ноутбуке. Ежедневная загрузка данных из глобальных инструментов и обработка этих данных в таблицах Excel становится все более монотонным мероприятием, которое требует все больше ручных операций и снижает производительности труда персонала RCM-центра. Рекомендуется в качестве внутренних хранилищ данных использовать реляционные СУБД (см. представление предлагаемого корпоративного решения).
  • Для реализации бизнес-операций RCM-центра предлагается применять ориентированную на процессы ИТ-систему на базе SOA.
  • Предлагается применять ESB-архитектуру на базе SOA с адаптерами WebSphere для интеграции данных в реальном времени с целью регистрации сведений, получаемых от стратегических инструментов для управления потребностями, предложением и персоналом, в предлагаемых внутренних реляционных СУБД.
  • Необходимо разработать Web-систему исполнения со следующими характеристиками: 1) сквозной поток работ с использованием механизма согласования IBM BPEL 2) сценарии применения, поддерживающие индивидуальные функции пользовательского интерфейса.
  • Необходимо подготовить план исполнения в предлагаемой системе исполнения и связать его с инструментом PMP.
  • Необходимо интегрировать план исполнения от предлагаемой системы с инструментом PMP.
  • Предлагаемая ИТ-система способна генерировать план исполнения на ежедневной основе.
  • Предлагаемое решение для автоматизации потока работ использует IBM BPEL при выборе решений в ручном режиме в PFM и CFE (с автоматизированной рабочей средой) с целью генерации плана исполнения.
  • Очистка и обогащение данных о предложении и потребностях производятся с помощью бизнес-правил на уровне ESB.
  • Из витрин данных извлекаются только ежедневные изменения в сведениях о предложениях и потребностях.
  • Осуществляется автоматическая предварительная проверка программного кода проекта и предъявление этого кода для каждой потребности с отправкой уведомления в GBS GD PM.

Система найма

  • Вместо инструмента HPAT на базе Lotus и таблиц Excel, которые в настоящее время используются при обмене информацией между RCM и подразделением управления персоналом, следует применять полнофункциональное Web-приложение найма на базе SOA. В Web-инструменте отслеживания должны быть реализованы следующие процессы: подготовка плана предложения, публикация, генерация запросов о найме, утверждение и закрытие, утверждения предложений/исключений. Следует создать Web-приложение для отслеживания вопросов найма, обеспечивающее онлайновое взаимодействие между различными заинтересованными сторонами.
  • Следует обеспечить «чистую» интеграцию между Web-системой найма и инструментом GOM. Отслеживание всех событий управления персоналом, связанных с определенным идентификатором запроса, должно осуществляться посредством передачи зарегистрированных событий из инструмента GOM в Web-систему найма. Рекомендуется запросы по найму от предлагаемой системы найма публиковать в инструменте GOM – посредством интеграции данных или посредством интеграции приложений на основе детальных сведений, получаемых из структуры данных GOM.
  • Следует разработать сценарии применения, связанные с задачами утверждения предложений и исключений в системе найма.
  • Приложение готовит запрос на генерацию кода о служебном положении в системе найма, а затем через Web-сервис обращается к системе управления персоналом (HRMS) для получения этого кода.
  • Хостинг Web-сервиса генерации кодов служебного положения следует осуществлять в HRMS-системе.
  • Необходимо разработать Web-систему найма со следующими характеристиками: 1) сквозной поток работ с использованием механизма согласования IBM BPEL 2) сценарии применения, поддерживающие индивидуальные функции пользовательского интерфейса.
  • Следует разработать системный DPI-сервис для конвейерной обработки нераспределенных ANOB-кандидатов.
  • Ручной режим не должен использоваться при отправке запросов по найму в систему найма.
  • Обновления потребностей по найму от руководителей SLC должны осуществляться посредством Web-системы найма.
  • Должен присутствовать автоматический сервис согласования, сопоставляющий детальные сведения ANOB с детальными сведениями запроса с целью его закрытия.
  • Должен присутствовать автоматический сервис PeM (обновленный сервис Connection Advisor) для кандидатов, включенных в конвейер.
  • Должен присутствовать автоматический сервис распределения конвейера с использованием бизнес-правил на базе DPI.
  • Должен присутствовать автоматический сервис преобразование плана предложений в план запросов по найму с помощью заранее созданного бизнес-правила.

Представление корпоративного RCM-решения

В этом разделе архитектура модернизированного RCM-центра описывается на уровне корпоративных сервисов, представленном в виде архитектурной модели типа S3 (IBM SOA Solution Stack). S3-модель весьма полезна для архитекторов и проектировщиков при создании SOA-решений. В данном случае S3-моделирование было существенно расширено посредством выявления набора архитектурных компоновочных блоков для каждого уровня базовой S3-модели на основе лучших отраслевых методик и моделирования SOMA-сервисов. Полученная модель служит архитектурным руководством при создании архитектурной модели конкретного SOA-решения.

Рисунок 3. Представление RCM-центра с помощью S3-модели (SOA Solution Stack)
SOA solution stack view of RCM center
SOA solution stack view of RCM center

S3-представление (SOA Solution Stack) демонстрирует уровни SOA-архитектуры и ключевые компоненты решений. Функции уровней реализуются посредством разработки специальных компонентов и/или предоставляются инфраструктурным программным обеспечением связующего уровня. Горизонтальное измерение модели включает следующие пять уровней

  • Уровень бизнес-процессов
  • Уровень сервисов
  • Уровень компонентов сервисов
  • Функциональные и технические компоненты
  • Уровень оперативных систем

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

Уровень сервисов описывает сервисные контракты поддерживаемых сервисов. Он включает поддержку бизнес-сервисов, а также атомарные (детализированные) сервисы. Сервисные контракты описываются на языке WSDL (Web Service Description Language). Руководство политикой управления сервисами осуществляет уровень руководства. Пример списка потенциальных сервисов-кандидатов для планирования возможностей: сервис информирования о потребностях, сервис информирования о предложении, сервисы отображения. Подобно подсистемам найма, потенциальными сервисами-кандидатами являются: сервис генерации запроса о найме, сервис консолидации запросов, сервис утверждения запросов и т. д.

Уровень компонентов сервисов описывает компоненты поставщика сервисов, обеспечивающие реализацию сервисных контрактов. Компоненты сервисов включают функциональные компоненты и технологические компоненты. Функциональные компоненты реализуются подсистемами. Подсистема может состоять из одного или из нескольких компонентов сервисов. В рассматриваемой модернизации RCM-центра в многоуровневой SOA-модели каждому сервисному компоненту соответствует подсистема, которая, в свою очередь, состоит из нескольких функциональных компонентов (см. диаграмму на рис. 3).

Уровень оперативных систем включает существующие глобальные системы и инструменты IBM, используемые для операций RCM-центра. Инструмент PMP предназначен для регистрации потребностей и их распределения для последующего исполнения. Инструмент GOM (Global Opportunity Marketplace) используется подразделением управления персоналом для сбора информации по новому сотруднику. Инструмент PD используется для информирования о внутренних предложениях с детальными сведениями по набору навыков. Инструменты Blue pages/Live core DB используются для регистрации детальных сведений о кандидате при генерации отчета о предложении. HRIS-система используется для обновления детальных сведений о кандидате; код служебного положения генерируется на основе информации BUCOMG, PAL и PeM. Глобальный стратегический инструмент OODB от IBM используется вместо нынешнего инструмента SSP IS на базе Lotus Notes. Надлежащие интерфейсы для этих существующих инструментов предлагаются в составе системы модернизации RCM-центра.

Вертикальное измерение содержит следующие четыре уровня:

  1. Уровень интеграции
  2. Уровень QoS (Quality of Service – обеспечения качество сервиса)
  3. Уровень архитектуры данных
  4. Уровень руководства

Уровень интеграции поддерживается посредством таких компонентов, как Integration Controller и Message Transformer. В состав Integration Controller входит шлюз Gateway Enterprise Service Bus (ESB) и внутренняя шина ESB. ESB - это управляемая инфраструктура для выполнения следующих функций: преобразование транспортных протоколов, виртуализация/маршрутизация конечных точек сервисов, посредничество между сервисами (в т.ч. сервисами преобразования сообщений, регистрации и безопасности). ESB служит интерфейсом для среды исполнения Service Registry и Service Management, обеспечивающим управление исполнением сервисов. Инфраструктура Gateway ESB обеспечивает функционирование механизмов безопасности (технология HTTPs и опция Web Service Security) на основе предлагаемой для RCM-центра инфраструктуры связующего уровня.

Зоны интеграции предлагаемой системы модернизации RCM-центра с существующими оперативными системами:

  • План исполнения, поступающий в PMP от подсистемы исполнения, предлагаемой для модернизации RCM-центра.
  • Между GOM и подсистемой найма, предлагаемой для модернизации RCM-центра (в качестве замены для инструмента HPAT).
  • Интеграция сведений о потребностях/предложениях от инструмента PMP с системой исполнения, предлагаемой для модернизации RCM-центра.

Уровень архитектуры данных представляет собой набор репозитариев данных (на основе предлагаемых реляционных СУБД) для хранения сведений о предложении, потребностях, найме и исполнении. В настоящее время все сведения о предложении и потребностях обрабатывается в форме текстовых файлов и таблиц Excel, загружаемых из G42-отчетов о потребностях (получаемых от инструмента PMP), и в виде информации из отчетов о предложении (получаемых от разных инструментов). В предлагаемых RDBMS-репозитариях (с помощью таких механизмов, как интеграция данных, модули-посредники и набор бизнес-правил) данные о предложениях и потребностях от PMP копируются и обогащаются детальными сведениями, содержащимися в репозитарии базы данных исполнения. В дополнение к детальной информации от бизнес-подразделений репозитарий исполнения содержит внутренние и внешние сведения по предлагаемому плану исполнения. Он также содержит данные по сквозному исполнению транзакций, включая сведения по вновь принятому сотруднику от подсистемы найма, которые подлежат сопоставлению с соответствующей потребностью. Кроме того, этот репозитарий поддерживает нераспределенные детальные ANOB-данные для сопоставления кандидатов. После истечения установленного периода времени результаты аудита подлежат отправке в архивные базы данных.

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

Уровень QOS обеспечивает оперативное управление и мониторинг исполнения процессов и сервисов. Этот уровень поддерживается инфраструктурным программным обеспечением для управления сервисами, в качестве которого могут быть использованы продукты IBM Tivoli® для управления сервисами или написанное собственными силами ПО для мониторинга сервисов/управления сервисами (включая сервисы безопасности). С целью повышения производительности мониторинга и управления транзакционными данными предложены сервисы кэширования на различных архитектурных уровнях, а также механизмы периодического перемещения данных на длительное хранение.

Уровень руководства оказывает поддержку при управлении всеми оперативными сервисами RCM-центра. В RCM-центре имеют место следующие процессы руководства операциями:

  • Процесс руководства кадровым резервом
  • Процесс руководства ротацией
  • Процесс руководства высвобождением
  • Процесс руководства наймом
  • Процесс руководства исполнением
  • Процесс руководства контролем над потребностями

Все вышеперечисленные процессы управления должны быть сформированы посредством создания трехуровневого руководящего органа, состоящего из руководителей, высших должностных лиц и исполнительных менеджеров RCM-центра, HR-подразделения, SLC-подразделения и секторов.

Методика SOMA для идентификации сервисов: пример бизнес-компонента – наем трудовых ресурсов

Декомпозиция процесса

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

1.1. Подготовка плана предложения
1.2. Генерация и отслеживание запроса о найме
1.3. Рекрутирование трудовых ресурсов
1.4. Распределение ресурсов
1.5. Закрытие запроса о найме

На следующем уровне декомпозиции осуществляется разбиение на следующие компоненты

1.1. Подготовка плана предложения
1.1.1. Создание плана предложения
1.1.2. Публикация плана предложения
1.1.3. Утверждение плана предложения (в контексте найма)

1.2. Генерация и отслеживание запроса о найме
1.2.1. Идентификатор запроса (ID)
1.2.2. Отслеживание запроса о найме

1.3. Процесс рекрутирование трудовых ресурсов
1.3.1. Отыскание и выбор
1.3.2. Обработка предложений

1.4. Распределение ресурсов
1.4.1. Получение сведений о потребностях
1.4.2. Распределение ресурсов
1.4.3. Генерация кода служебного положения

1.5. Закрытие запроса о найме
1.5.1. Процесс согласования
1.5.2. Процесс закрытия запроса

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

Рисунок 4. Уровень 3. Декомпозиция процесса найма
level 3 Process Decomposition of Hiring component
level 3 Process Decomposition of Hiring component
Рисунок 5. Портфель сервисов
Service Portfolio
Service Portfolio

Анализ, ориентированный на изменения

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

Атрибуты класса «тип найма» определяют, на каких условиях осуществляется найм: полный рабочий день на постоянной основе в IBM, полный рабочий день на постоянной основе у подрядчика IBM (SSP), неполный рабочий день в IBM и т.д. В зависимости от атрибута «тип найма» будут меняться подпроцессы найма в этих каналах найма. Наем в SSP осуществляется согласно восходящему подходу, т.е. базируется на спецификации потребностей от инструмента PMP. Для 90 - 95% постоянных вакансий в IBM запрос о найме формируется на основе плана предложения, а для остальных 10 – 15% запрос о найме формируется из запроса к инструменту PMP относительно потребностей в заполнении вакантных должностей. Таким образом, мы классифицировали процесс найма по типу запроса о нанимаемых трудовых ресурсах (см. рис. 6). Остальные атрибуты класса (JRSS/Band/Location) характерны для найма любых трудовых ресурсов. По результатам этого анализа, ориентированного на изменения, мы выявили еще несколько сервисов, перечисленных ниже.

  1. Получение запросов о найме на основе плана предложения
  2. Получение запросов о найме на основе данных от инструмента PMP о потребностях в заполнении вакантных должностей
  3. Получение запросов о найме от SSP
  4. Получение запросов о найме в IBM на постоянной основе
  5. Получение запросов о найме, совпадающих с критериями JRSS/Band, на основе плана предложения
  6. Получение запросов о найме, совпадающих с критериями JRSS/Band, на основе данных от инструмента PMP о потребностях в заполнении вакантных должностей
  7. Получение запросов о найме, совпадающих с критериями JRSS/Band/location, на основе плана предложения
  8. Получение запросов о найме, совпадающих с критериями JRSS/Band/location, на основе данных от инструмента PMP о потребностях в заполнении вакантных должностей
  9. Получение запросов о найме, совпадающих с критериями JRSS, для SSP
  10. Получение запросов о найме, совпадающих с критериями JRSS/location, для SSP и т.д.
Рисунок 6. Представление анализа, ориентированного на изменения в области найма
Hiring Variation Oriented Analysys View
Hiring Variation Oriented Analysys View

Моделирование цели сервиса

В таблице 1 показаны цели, показатели и KPI-индикаторы, установленные для процесса найма ресурсов.

Таблица 1. Цели и KPI-индикаторы
ЦельKPI-индикатор
Немедленное включение принимаемых трудовых ресурсов в проекты IBMКадровый резерв < целевой показатель организации
Смягчение сильных колебаний потребностей посредством упреждающей генерации запросов о найме на основе плана предложенияПродолжительность поддержания нулевого уровня потребностей > 30 суток (для определенных каналов найма)

Продолжительность поддержания нулевого уровня потребностей > 30 суток (для определенных каналов найма)

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

Идентификация подцелей для поддержания нулевого уровня потребностей в каналах найма на протяжении более 30 суток

  • На основе плана предложения распределить создание запросов о найме для подобных наборов навыков по разным временным интервалам – это улучшит контроль над запросами о найме.
    • Создать сервис для отслеживания одинаковых наборов навыков и состояния найма.
  • Выявить навыки, востребованные на рынке на текущий момент времени, и разместить дополнительные запросы (помимо запросов к плану предложения).
    • Создать сервис для выявления навыков, востребованных на рынке в данный момент.

Анализ существующих активов

На данный момент не существует никаких ИТ-систем, поддерживающих операции найма трудовых ресурсов со стороны RCM-центра, есть только система GOM, которая поддерживает операции, связанные с управлением персоналом. Инструменты SSPIS и HPAT, построенные на базе приложений Lotus, не могут рассматриваться в качестве средства задействования имеющихся активов, поскольку применяемая в RCM-центре политика требует отказа от любых инструментов на базе Lotus Notes.

Заключение

После исчерпывающего исследования текущих операций RCM-центра (Индия) и применяемых при этом инструментов, а также после понимания проблем различных заинтересованных сторон этого RCM-центра, мы предложили построить соответствующее ИТ-решение для систем исполнения и найма. Эти предлагаемые системы используют родственные глобальные стратегические инструменты IBM PMP и IBM GOM для интеграции с целью достижения полноты функциональных возможностей. Предлагаемые системы построены на основе SOA-стандартов, легко подключаются к существующим инструментам, а также обладают высокой степенью масштабируемости и конфигурируемости, что позволяет разместить их в любом из глобальных сервисных центров IBM, расположенных по всему миру.

Благодарности

Авторы выражают благодарность за поддержку при написании данной статьи следующим лицам: Рохини Баладжи, BT&IT, Global Delivery Center и бизнес-аналитику RCM Верендре Малласандре.


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=859617
ArticleTitle=Модернизация RCM-центра (Resource and Capacity Management) на основе методики CBM-SOMA
publish-date=02262013