Лекция
Привет, сегодня поговорим про планирование трудових ресурсов проекта, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое планирование трудових ресурсов проекта , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.
Планирование человеческих ресурсов - процесс определения и документального оформления ролей, ответственности и подотчетности, а также создание плана управления обеспечением проекта персоналом [16].
При распределении ролей и ответственности, необходимых для выполнения проекта, следует учитывать следующие моменты.
Роль в проекте ( проектная роль ) - определенный набор функций и полномочий в проекте, созданный с целью распределения обязанностей между членами команды проекта. Проектную роль можно рассматривать как временную должность в организации (компании).
Полномочия - право задействовать ресурсы проекта, принимать решения и утверждать одобрение действий или результатов. Примеры полномочий: выбор способа завершения операции, приемка качества и порядок реагирования на отклонения в проекте.
Ответственность - работа, которую член команды проекта должен выполнить для завершения операций проекта.
Квалификация - навыки и способности, необходимые для выполнения операций проекта. Отсутствие нужной квалификации у членов команды влияет на расписание проекта, качество выполнения работ, ставит под угрозу цели проекта. Для повышенияквалификации планируют проведение обучения членов команды.
Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения.
Со стороны заказчика ключевые роли играют спонсор проекта и менеджер проекта со стороны заказчика. Спонсор проектаобеспечивает организационную сторону проекта и подтверждает правильность целей проекта. В его ведении находится бюджет проекта. Спонсором проекта может быть отдельный человек или целый комитет, в зависимости от масштабов и сложности проекта. Менеджер проекта со стороны заказчика назначается и в том случае, если осуществление проекта организацией заказчика требует ежедневного управления. В его обязанности входит предоставление ресурсов заказчиков, разрешение проблем и отслеживание состояния проекта.
Ключевые роли со стороны исполнителя - руководитель проекта (менеджер проекта) со стороны исполнителя и бизнес-менеджер.
Бизнес-менеджер отвечает за успешное выполнение проекта и представляет исполнителя в его договорных отношениях с заказчиком. Менеджер проекта (руководитель проекта) отвечает как за успехи, так и за неудачи проекта. В его задачи входит управление сроками, стоимостью, качеством работ с целью удовлетворения ожиданий заказчика и достижения бизнес-целей исполнителя.
Команда управления проектом включает координатора проекта, администратора проекта, менеджера по конфигурации. Для крупных проектов к выполнению каждой из этих ролей могут быть привлечено нескольких человек. На небольших проектахменеджер проекта может совмещать несколько ролей. Масштабные проекты предполагают наличие менеджера по качеству, который ответственен перед бизнес-менеджером исполнителя.
В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].
Приведенный список ключевых ролей команды управления проектом является необходимым для управления работами при внедрении информационной системы. Возможны некоторые модификации состава команды в зависимости от сложности и масштабности проекта, например, при необходимости можно включать в нее заместителя руководителя проекта, руководителей функциональных направлений (финансы, логистика, персонал и т. д.).
Состав команды управления должен быть достаточным, чтобы осуществлять [11]:
o определение требуемых для достижения целей проекта ресурсов;
o подготовка предложений по изменению состава группы управления проектом;
o утверждение персональных изменений в составе рабочих групп проекта;
o оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов;
o подготовка плана работ проекта;
o контроль над выполнением проекта;
o подготовка отчетов о ходе работ проекта;
o контроль соответствия разрабатываемых проектных решений техническому заданию;
o организация экспертизы проектных решений;
o анализ рисков проекта;
o разработка планов мероприятий по снижению рисков;
o реализация мероприятий по снижению рисков;
o анализ проблем проекта;
o разработка мероприятий по разрешению проблем проекта;
o реализация мероприятий по разрешению проблем проекта;
o согласование отчетов о ходе работ;
o контроль над функционированием системы сбора и распределения информации;
o контроль документирования проектных результатов.
В состав команды проекта входят не только команда управления проектом, но и исполнители проекта. Примеры проектных ролейисполнителей, характерных для IT-проектов: функциональный архитектор, функциональный консультант, разработчик,администратор ИС, тестировщик, менеджер по качеству, системный аналитик. В проекте один член команды может выступать одновременно в нескольких ролях. Совмещение ролей часто встречается в небольших проектах, что позволяет снизить накладныерасходы проекта. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей, как руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика.
На стадии планирования в рамках процесса управления человеческими ресурсами не предусматривается долгосрочное планирование, а составляется план для реализации первого этапа проекта. Основными задачами являются разработка организационной структуры проекта и подбор персонала.
Работа по планированию организационной структуры проводится менеджером проекта со стороны исполнителя совместно с менеджером со стороны заказчика. Путем переговоров достигается соглашение об уровне, на котором должно производиться утверждение выделяемых ресурсов заказчика и обсуждение требований к членам команды исполнителя. Администратор проекта фиксирует результаты переговоров.
Иерархические организационные диаграммы являются простым и наглядным инструментом для определения иерархии подотчетности, начиная с нижнего уровня организации до руководителя проекта.
Рис. 11.1. Пример организационной структуры проекта
Существуют различные форматы документирования распределения ролей и ответственности членов команды проекта, например, иерархический, матричный или текстовый. Независимо от формата документирования организационные диаграммы позволяют для каждого пакета работ назначить ответственного за его исполнение, а также обеспечивают понимание своей роли и ответственности каждым членом команды.
На рис. 11.1 представлен пример организационной структуры проекта, документирования распределения ролей и ответственности членов команды проекта, выполненного в виде организационной структуры. Организационная структура является иерархической организационной схемой существующих подразделений организации (отделов, групп или команд). Под каждым отделом указывается список операций проекта или пакета работ. Таким образом можно увидеть закрепление ответственности в проекте для данного функционального отдела (например, отдела информационных технологий или отдела закупок) в одном месте рядом с названием отдела.
Для отражения иерархии подотчетности на проекте и указания обязанностей каждой из групп, входящих в проектную команду, в документ описания содержания проекта рекомендуется включить матрицу ответственности, наиболее распространенный вариант которой известен как RACI-матрица. Использование данного инструмента особенно актуально в ситуации, когда проектная командасостоит из представителей различных юридических лиц (например, типичная команда на проекте внедрения КИС включает в себя сотрудников заказчика, генерального подрядчика и субподрядчиков). Матрица ответственности решает задачу демонстрации межорганизационного или межгруппового взаимодействия и, как следствие, позволяет избежать недоразумений, которые время от времени возникают в проектах между подразделениями и организациями из-за неясности, к кому следует обращаться по тем или иным вопросам и кто должен принимать по ним решение, а кто - непосредственно реализовать принятую резолюцию.
Важно как можно раньше произвести размежевание всех формальных полномочий, прав и обязанностей, пока команда проекта еще не приступила к активной работе. В противном случае, когда у сотрудников сложится собственное представление о своем месте в проекте, расхождения во мнениях по этим вопросам могут перерасти в затяжные конфликты и оказать значительное негативное влияние на график выполнения проекта.
Построение матрицы ответственности
1. Перечислить основные работы проекта.
По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3 ИСР), но с достаточной степенью детализации для обеспечения возможности указывать разные роли, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации.
2. Перечислить группы/роли внутри проектной команды.
По горизонтали в матрице перечисляются группы/ роли внутри проектной команды. Обратите внимание на то, что в матрице ответственности группы/роли, а не имена и фамилии отдельных членов коллектива. Персональное закрепление проектных работ производится позднее, на этапе разработки расписания проекта.
3. Закодировать матрицу ответственности.
С помощью кодов в ячейках на пересечении соответствующих столбцов с ролями и строк с работами проекта указать степень участия, формальные полномочия и распределение ответственности за выполнение каждой операции. Четкое указание разных уровней формальных полномочий бывает особенно полезно в ситуации, когда множество членов проектной команды желает предъявить особые требования к проекту.
Таблица 11.1. Условные обозначения матрицы ответственности (RACI)
|
Обозначение |
Расшифровка |
Описание |
|
Исп. (R) |
Исполнитель (Responsible) |
Несет ответственность за непосредственное исполнение задачи. К каждой задаче должно быть приписано не менее одного исполнителя |
|
Утв. (A) |
Утверждающий (Accountable) |
Отвечает за конечный результат перед вышестоящим руководством. На каждую работу должен быть назначен строго один подотчетный |
|
Cогл. (C) |
Согласующий (Consulted) |
Согласует принимаемые решения, взаимодействие с ним носит двусторонний характер |
|
Н. (I) |
Наблюдатель (Informed) |
Его информируют об уже принятом решении, взаимодействие с ним носит односторонний характер |
Таблица 11.2. Распределение функциональных обязанностей команды управления проектом
|
Функциональные обязанности |
Куратор проекта (Спонсор) |
Руководитель проекта |
Архитектор системы |
Администратор проекта |
|
Планирование |
||||
|
Разработка и периодическая актуализация плана |
+ |
+ |
||
|
Утверждение плана |
+ |
|||
|
Управление командой проекта |
||||
|
Назначение сотрудника на роль Руководителя проекта |
+ |
|||
|
Формирование команды проекта |
+ |
|||
|
Определение квалификационных требова ний и состава рабочих групп специалистов по функциональности ИС |
+ |
|||
|
Обеспечение выделения необходимых ресурсов для выполнения проекта |
+ |
|||
|
Непосредственное руководство Командой проекта |
+ |
|||
|
Формирование предложений по стимулированию Команды проекта |
+ |
|||
|
Обеспечение стимулирования Команды проекта |
+ |
|||
|
Организация выполнения работ |
||||
|
Организация взаимодействия с Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта |
+ |
|||
|
Организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта |
+ |
|||
|
Организация, проведение и документирование процедур передачи Заказчику разработанной ИС |
+ |
+ |
||
|
Рассмотрение и утверждение регламентирующих документов, необходимых для организации и выполнения проекта |
+ |
|||
|
Ведение организационно-распорядительной и отчетной документации. Поддержание в актуальном состоянии списка команды проекта |
+ |
|||
|
Обеспечение команды проекта необходимыми информационными материалами |
+ |
|||
|
Материально-техническое и хозяйственное обеспечение команды проекта |
+ |
|||
|
Контроль хода выполнения проекта |
||||
|
Организация и проведение совещаний по обсуждению хода работ проекта |
+ |
|||
|
Подготовка и предоставление Куратору отчетов о ходе работ проекта |
+ |
|||
|
Получение и анализ сводной отчетности о ходе реализации проекта |
+ |
|||
|
Контроль соответствия результатов проекта Техническому заданию на разработку ИС |
+ |
|||
|
Согласование фактических трудозатрат специалистов при исполнении проекта |
+ |
+ |
На коды, используемые в матрице ответственности, каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)), в котором приведено описание соответствующих кодов.
4. Инициировать использование матрицы и включить процедуру использования матрицы ответственности в документ "План управления проектом".
После утверждения матрицы ответственности все дальнейшие изменения в ней должны проходить через процедуру интегрированного управления изменениями при участии авторов первоначальной версии.
Преимущество использования структурированного подхода к изменению матрицы ответственности состоит в том, что руководитель проекта получает актуальный документ, на который он может ссылаться при возникновении тех или иных спорных ситуаций, касающихся распределения полномочий в проекте.
В частности, матрица ответственности может быть использована для распределения основных функциональных обязанностей. Так, в табл. 6.2 в левом столбце перечислены функциональные обязанности, соответствующие проектным работам, список которых составлен на основе используемой методологии и накопленного проектного опыта, а в правую часть таблицы вносится отметка о степени ответственности и участия каждого из члена группы управления проектом в исполнении соответствующей функции.
Ранее в разделе, посвященному формированию устава проекта, мы уже кратко описывали характер ролей и основные должностные инструкции членов группы управления проектом. В данном же разделе мы подробно рассмотрим этот аспект и сформируем более детальный список функций и полномочий для каждой из упомянутых ниже ролей.
Куратор проекта (спонсор) - проектная роль должностного лица, отвечающего за стратегическое управление ходом реализации проекта. Куратор принимает решение по стратегическим вопросам проекта, осуществляет утверждение основных изменений в объеме работ, сроках, этапах, в бюджете проекта, находящихся вне компетенции руководителя проекта. Как правило, куратором проекта (спонсором) является менеджер высшего звена организации.
Основные функции:
Основные полномочия:
Руководитель проекта - проектная роль должностного лица, ответственного за управление проектом.Руководитель проектанепосредственно отвечает за достижение целей проекта в рамках выделенного бюджета, в соответствии с плановыми сроками осуществления проекта и с заданным уровнем качества.
Основные функции:
Основные полномочия:
Архитектор системы - проектная роль должностного лица, отвечающего за предметную область проекта. Архитектор системы подчиняется непосредственно руководителю проекта.
Архитектор системы непосредственно отвечает за разработку информационной системы в соответствии с плановыми сроками проекта и с заданным уровнем качества.
На роль архитектора системы назначается специалист, наиболее компетентный по внедряемой информационной системе.Архитектор системы должен знать методологии и технологии построения ИС, стандарты и нормативные документы в области проектирования и создания ИС, разработки и оформления технической документации.
Основные функции:
Основные полномочия:
Администратор проекта - проектная роль должностного лица, отвечающего за информационное обеспечение руководителя проекта, организацию и ведение документооборота по проекту. Администратор проекта функционально закрепляется за конкретным проектом и подчиняется непосредственно руководителю проекта.
Основные функции:
Для того чтобы закрепить функции и обязанности по проекту, составляют ролевые инструкции или положение по проектной роли. В ролевой инструкции должно быть определено следующее:
Крайне важное замечание, высказываемое многими экспертами, состоит в том, что определение ролей и ответственности в проекте должны производиться с учетом факторов внешней среды предприятия. В табл. 11.3 приведены примеры возможного влияния организационных, технических, межличностных, политических и прочих факторов на процесс планирования команды проекта.
Таблица 11.3. Влияние факторов внешней среды на планирование команды проекта
|
Факторы внешней среды |
Влияние на определение ролей команды и ответственности |
|
Организационные |
Взаимоотношения организаций или отделов, участвующих в проекте, механизмы взаимодействия между ними |
|
Технические |
Навыки и специальности, необходимые для выполнения проекта, необходимость обеспечения координации между языками программного обеспечения, наличие специфических сложностей при переходе от одной фазы жизненного цикла к другой |
|
Межличностные |
Официальные и неофициальные отношения между потенциальными членами команды проекта, их должностные обязанности. Об этом говорит сайт https://intellect.icu . Культурные или языковые различия между членами команды, которые могут оказать влияние на их рабочие взаимоотношения |
|
Политические |
Цели и интересы потенциальных членов команды проекта, люди (или группы людей), которые имеют неформальное влияние в областях, представляющих важность для проекта, существование неформальных связей между потенциальными участниками проекта |
На этапе планирования для каждой роли должен быть определен список навыков, необходимых членам команды проекта. Для разработки списка рекомендуется использовать реестр навыков - список категорий и компонентов навыков для определенного класса команды исполнителей проекта (см.табл. 11.4).
Для обеспечения анализа совокупностей навыков компоненты группируются в четыре категории: технические навыки, административные, навыки межличностного общения, стратегические навыки. Для каждого навыка отмечаются рейтингкритичности и рейтинг способностей [12]. Для оценки рейтинга принято использовать 4-балльную шкалу (см. табл. 11.5).
Таблица 11.4. Реестр навыков для команды исполнителей проекта
|
Категории и компоненты навыков |
|
|
Технические навыки
|
Навыки межличностного общения и лидерства
|
|
Административные навыки
|
Стратегические навыки
|
Реестры навыков должны быть составлены для каждого класса персонала, как, например, для руководителя проекта, системного архитектора, специалиста по качеству. Критичность навыков для руководителя проекта определяется во многом масштабом проекта и организационной структурой проекта. Наибольшими полномочиями наделен руководитель проекта в проектных организационных структурах, и следовательно, к нему должны предъявляться самые высокие требования. Список навыков может быть определен на основе профессиональных стандартов в области информационных технологий. Распределение навыков зависит от уровня административной ответственности. Рейтинг критичности смещается от "технических" в сторону "административных", а затем в сторону "межличностного общения" и "стратегических навыков" по мере роста административной ответственности. Следует подчеркнуть важность навыков межличностного общения. Команда проекта может многократно снизить количество возникающих проблем и повысить взаимодействие сотрудников, если будет понимать настроение членов команды проекта, предвидеть их действия, внимательно выслушивать и признавать их мнение и решать их проблемы. Для управления командой проекта и работы в проекте такие навыки, как умение сопереживать, оказывать влияние, творческий подход к работе и способность облегчать работу группы, приобретают значение ценных активов. После того как реестр сформирован, он может быть использован с минимальной точной подстройкой к новой проектной ситуации
Пример разработки реестра навыков
Ниже (табл. 11.5, табл. 11.6) выделены категории навыков для консультантов и менеджеров проектов: технические, административные, навыки межличностного общения, стратегические навыки. Для каждого консультанта (как при приеме на работу, так и при зачислении в команду проекта) необходимо проводить оценку навыков по шкале 1-4 ("плохо", "удовлетворительно", "хорошо", "отлично" соответственно)
Стоит подробно остановиться на том, каким образом оценивать технические компетенции консультантов компании. Это наиболее важные навыки, которые необходимо учитывать при планировании сотрудников на проекты.
Таблица 11.5. Шкала рейтингов критичности и способностей
|
Рейтинг |
Критичность |
Квалификация |
|
1 |
Неважно/Маловажно |
Отсутствие навыков / слабые навыки |
|
2 |
Важно |
Базовые навыки |
|
3 |
Очень важно |
Высокая квалификация |
|
4 |
Критично для успеха проекта |
Уникальная квалификация |
Таблица 11.6. Реестр навыков для членов команды исполнителей
|
Категории и компоненты навыков |
Критичность |
ФИО |
|
Технические навыки (категория I)
|
Очень важно |
Хорошо |
|
Административные навыки (категория II)
|
Важно |
удовлетворительно |
|
Навыки межличностного общения и лидерства (категория III) Навыки общения
|
Очень важно |
хорошо |
|
Стратегические навыки (категория IV)
|
В некоторой степени важно |
отлично |
Таблица 11.7. Реестр навыков члены команды управления проекта
|
Категории и компоненты навыков |
Критичность |
Способности |
|
Технические навыки (категория I)
|
В некоторой степени важно |
|
|
Административные навыки (категория II)
|
Важно |
|
|
Навыки межличностного общения и лидерства (категория III)
|
Очень важно |
|
|
Стратегические навыки (категория IV)
|
Важно |
|
В консалтинговых компаниях, в том числе системных интеграторах, довольно сильно распространена практика разделения консультантов на так называемые грейды, или уровни, в соответствии с их технической компетенцией и возможностями выполнения тех или иных задач1 Пример четко сформулированных требований к грейдам представлен в сводной табл. 11.8 - в ней приведен пример описания технической компетенции консультанта по внедрению модуля управления человеческими ресурсами в системе SAP.
Таблица 11.8. Реестр технических компетенций
|
Уровень 1 |
Вес |
Уровень 2 |
Вес |
Уровень 3 |
Вес |
|
Компоненты НСМ-1 |
70 |
Администрирование персонала |
12 |
Бизнес-процессы |
2 |
|
Инфотипы |
1 |
||||
|
Мероприятия |
2 |
||||
|
Стажи |
2 |
||||
|
Отчетность |
4 |
||||
|
Интерфейсы |
1 |
||||
|
Управление временными данными |
10 |
Бизнес-процессы |
1 |
||
|
Графики |
0,3 |
||||
|
Отсутствие, присутствие |
1 |
||||
|
Лимиты |
1,5 |
||||
|
Временные события |
1 |
||||
|
Оценка времени |
1,5 |
||||
|
Рабочий стол менеджера |
0,5 |
||||
|
Планирование смен |
0,7 |
||||
|
Сдельная оплата труда |
2 |
||||
|
Отчетность |
1 |
||||
|
Расчет заработной платы |
21 |
Бизнес-процессы |
1 |
||
|
Инфотипы |
1 |
||||
|
Расчет базовых видов оплат |
2 |
||||
|
Расчеты по среднему |
2 |
||||
|
Налоги |
2 |
||||
|
Удержания |
3 |
||||
|
Внециклические расчеты |
3 |
||||
|
Перечисления |
1 |
||||
|
Проводки |
3 |
||||
|
Отчетность |
3 |
||||
|
Организационный менеджмент |
5 |
Бизнес-процессы |
0,5 |
||
|
Стандартные объекты, инфотипы, связи |
1 |
||||
|
Интеграция с другими компонентами |
0,5 |
||||
|
Архитектура иерархии |
1 |
||||
|
Собственные объекты, инфотипы, связи |
1 |
||||
|
Версии плана. Статусы объектов |
0,5 |
||||
|
Отчетность |
0,5 |
||||
|
Льготы, предоставляемые работодателем |
3 |
Бизнес-процессы |
1 |
||
|
Инфотипы |
1 |
||||
|
Отчетность |
1 |
||||
|
Управление глобальными сотрудниками |
3 |
Инфотипы |
0,5 |
||
|
Процесс |
1 |
||||
|
Компенсационный пакет |
0,5 |
||||
|
Расчет заработной платы |
1 |
||||
|
Управления сотрудниками, имеющими несколько контрактов |
5 |
Процессы администрирования |
1 |
||
|
Управление временем |
1 |
||||
|
Льготы, предостав-ляемые работодателем |
0,5 |
||||
|
Расчет заработной платы |
2 |
||||
|
Проводки |
0,5 |
||||
|
Управление бюджетами должностей |
3 |
Обязательства |
0,5 |
||
|
Бюджеты |
0,5 |
||||
|
Интеграция с другими компонентами |
1 |
||||
|
Управление бюджетами |
1 |
||||
|
Управление командировками |
5 |
Бизнес-процессы |
1 |
||
|
Планирование |
1 |
||||
|
Командировочные расходы |
2 |
||||
|
Отчетность |
1 |
||||
|
Пенсионные фонды |
3 |
Бизнес-процессы |
1 |
||
|
Функции |
1 |
||||
|
Интеграция с другими компонентами |
0,5 |
||||
|
Отчетность |
0,5 |
||||
|
Программирование в НСМ-1 |
19 |
Стандартная отчетность/SAP Query/BW |
2 |
Использование стандартных отчетов |
1 |
|
BW content для НСМ-1 |
0,5 |
||||
|
Расширения для SAP Query |
0,5 |
||||
|
Workflow в HCM-1 |
5 |
Базовый процесс |
2 |
||
|
Workflow в Администрирование персонала |
1 |
||||
|
Wbrkflow в управлении временными данными |
1 |
||||
|
Wjrkflow в управлении командировками |
1 |
||||
|
АВАР в НСМ-1 |
10 |
АВАР workbench |
4 |
||
|
User-exits, badis, includes, enhancements |
1 |
||||
|
АВАР репозиторий |
2 |
||||
|
MS Office integration (OLE, DPI), Adobe |
1 |
||||
|
ALV |
2 |
||||
|
Drilldown отчетность + HR forms |
2 |
Создание drilldown отчетов |
1 |
||
|
Создание Hrforms отчетов |
1 |
||||
|
Администрирование в НСМ-1 |
11 |
Полномочия |
3 |
Настройка ролей, полномочий |
1,5 |
|
Структурные полномочия |
1 |
||||
|
Полномочия, зависимые от контента |
0,5 |
||||
|
ALE |
2 |
Модель распределения |
1 |
||
|
Создание, изменение idoc |
1 |
||||
|
CATS |
2 |
Настройка CATS |
1 |
||
|
Интеграция с использованием CATS |
1 |
||||
|
LSMW+SXDA |
2 |
Batch input, direct input, BAPI |
1 |
||
|
Выгрузка во внешние системы |
1 |
||||
|
Архивация данных |
1 |
Процессы архивирования |
1 |
||
|
Archive Link |
1 |
Archive link |
1 |
||
В столбце "Вес" определено максимальное значение для навыка, исходя из общей значимости навыка для знания компонента в целом.
Следующим шагом требуется определить уровень сотрудников в разрезе каждого навыка и рассчитать общий коэффициент.
Далее, согласно технической компетенции, определяется грейд каждого сотрудника. Коэффициент определяется как суммарноезначение всех весовых значений по каждому навыку.
Таблица 11.9. Пример оценки технических навыков членов команды исполнителей проекта
|
Уровень 1 |
Вес |
Уровень 2 |
Вес |
Уровень 3 |
Вес |
Петров Иван |
Сидоров Артур |
|
Компоненты НСМ-1 |
70 |
Администрировав ние персонала |
12 |
Бизнес-процессы |
2 |
1,5 |
2 |
|
Инфотипы |
1 |
0,7 |
1 |
||||
|
Мероприятия |
2 |
1,5 |
2 |
||||
|
Стажи |
2 |
1 |
1,7 |
||||
|
Отчетность |
4 |
1 |
3 |
||||
|
Интерфейсы |
1 |
1 |
1 |
||||
|
Управление временными данными |
10 |
Бизнес-процессы |
1 |
0,8 |
1 |
||
|
Графики |
0,3 |
0,4 |
0,5 |
||||
|
Отсутствие, присутствие |
1 |
0,8 |
1 |
||||
|
Лимиты |
1,5 |
1 |
1,4 |
||||
|
Временные события |
1 |
0 |
0,5 |
||||
|
Оценка времени |
1,5 |
0,8 |
1,2 |
||||
|
Рабочий стол менеджера |
0,5 |
0,2 |
0 |
||||
|
Планирование смен |
0,7 |
0.1 |
0,7 |
||||
|
Сдельная оплата труда |
2 |
0,05 |
1,5 |
||||
|
Отчетность |
1 |
0,6 |
1 |
||||
|
Расчет заработной платы |
21 |
Бизнес-процессы |
1 |
0,8 |
1 |
||
|
Инфотипы |
1 |
0,8 |
1 |
||||
|
Расчет базовых видов оплат |
2 |
1 |
2 |
||||
|
Расчеты по среднему |
2 |
1,8 |
2 |
||||
|
Налоги |
2 |
1 |
1,5 |
||||
|
Удержания |
3 |
1 |
1,7 |
||||
|
Внециклические расчеты |
3 |
0,5 |
1 |
||||
|
Перечисления |
1 |
0,3 |
1 |
||||
|
Проводки |
3 |
1 |
3 |
||||
|
Отчетность |
3 |
1 |
2 |
||||
|
Организационный менеджмент |
5 |
Бизнес-процессы |
0,5 |
0,4 |
0,5 |
||
|
Стандартные объекты, инфотипы, связи |
1 |
0,3 |
0,7 |
||||
|
Интеграция с другими компонентами |
0,5 |
0,2 |
0,4 |
||||
|
Архитектура иерархии |
1 |
0 |
0,5 |
||||
|
Собственные объекты, инфотипы, связи |
1 |
0 |
0,2 |
||||
|
Версии плана. Статусы объектов |
0,5 |
0,1 |
0,4 |
||||
|
Отчетность |
0,5 |
0,1 |
0,5 |
||||
|
Льготы, предоставляемые работодателем |
3 |
Бизнес-процессы |
1 |
0 |
0,5 |
||
|
Инфотипы |
1 |
0 |
0 |
||||
|
Отчетность |
1 |
0 |
0 |
||||
|
Управление глобальными сотрудниками |
3 |
Инфотипы |
0,5 |
0 |
0 |
||
|
Процесс |
1 |
0 |
0,2 |
||||
|
Компенсационный пакет |
0,5 |
0 |
0 |
||||
|
Расчет заработной платы |
1 |
0 |
0,1 |
||||
|
Управления сотрудниками, имеющими несколько контрактов |
5 |
Процессы администрирования |
1 |
0 |
0,1 |
||
|
Управление временем |
1 |
0 |
0 |
||||
|
Льготы, предостав-ляемые работодателем |
0,5 |
0 |
0 |
||||
|
Расчет заработной платы |
2 |
0 |
0,2 |
||||
|
Проводки |
0,5 |
0 |
0 |
||||
|
Управление бюджетами должностей |
3 |
Обязательства |
0,5 |
0 |
0,3 |
||
|
Бюджеты |
0,5 |
0 |
0,3 |
||||
|
Интеграция с другими компонентами |
1 |
0 |
0,3 |
||||
|
Управление бюджетами |
1 |
0 |
0,5 |
||||
|
Управление командировками |
5 |
Бизнес-процессы |
1 |
0 |
0,4 |
||
|
Планирование |
1 |
0 |
0 |
||||
|
Командировочные расходы |
2 |
0 |
0 |
||||
|
Отчетность |
1 |
0 |
0 |
||||
|
Пенсионные фонды |
3 |
Бизнес-процессы |
1 |
0 |
0,5 |
||
|
Функции |
1 |
0 |
0,3 |
||||
|
Интеграция с другими компонентами |
0,5 |
0 |
0,3 |
||||
|
Отчетность |
0,5 |
0 |
0 |
||||
|
Программирование в НСМ-1 |
19 |
Стандартная отчетность/SAP Query/BW |
2 |
Использование стандартных отчетов |
1 |
0,7 |
1 |
|
BW content для НСМ-1 |
0,5 |
0,2 |
0,5 |
||||
|
Расширения для SAP Query |
0,5 |
0 |
0 |
||||
|
Workflow в HCM-1 |
5 |
Базовый процесс |
2 |
0 |
0,1 |
||
|
Workflow в Администрирование персонала |
1 |
0 |
0,2 |
||||
|
Wbrkflow в управлении временными данными |
1 |
0 |
0,1 |
||||
|
Wjrkflow в управлении командировками |
1 |
0 |
0 |
||||
|
АВАР в НСМ-1 |
10 |
АВАР workbench |
4 |
0,5 |
2 |
||
|
User-exits, badis, includes, enhancements |
1 |
0,05 |
0,5 |
||||
|
АВАР репозиторий |
2 |
0 |
1 |
||||
|
MS Office integration (OLE, DPI), Adobe |
1 |
0 |
0 |
||||
|
ALV |
2 |
0 |
1 |
||||
|
Drilldown отчетность + HR forms |
2 |
Создание drilldown отчетов |
1 |
0 |
0 |
||
|
Создание Hrforms отчетов |
1 |
0 |
0,5 |
||||
|
Администрирование в НСМ-1 |
11 |
Полномочия |
3 |
Настройка ролей, полномочий |
1,5 |
0,8 |
1 |
|
Структурные полномочия |
1 |
0,5 |
0,7 |
||||
|
Полномочия, зависимые от контента |
0,5 |
0 |
0,2 |
||||
|
ALE |
2 |
Модель распределения |
1 |
0 |
0,8 |
||
|
Создание, изменение idoc |
1 |
0 |
0 |
||||
|
CATS |
2 |
Настройка CATS |
1 |
0 |
0,5 |
||
|
Интеграция с использованием CATS |
1 |
0 |
1 |
||||
|
LSMW+SXDA |
2 |
Batch input, direct input, BAPI |
1 |
0,4 |
0,8 |
||
|
Выгрузка во внешние системы |
1 |
0 |
0,5 |
||||
|
Архивация данных |
1 |
Процессы архивирования |
1 |
0 |
0,2 |
||
|
Archive Link |
1 |
Archive link |
1 |
0 |
0,1 |
||
|
Итого |
24,9 |
55,7 |
В табл. 11.10 представлены требования к грейдам, разработанные на основании опыта внедрения проектов по функциональностиSAP HCM-1.
Важно не просто составить реестр такого рода, но и поставить цель - развитие навыков у максимального количества молодых сотрудников; только тогда организация может аккумулировать и поддерживать знания и навыки, которые она продает на рынке.
Таблица 11.10. Описание грейдов консультантов
|
Код |
Описание |
Коэффициент |
|
К1 |
Консультант-стажер |
0-19 |
|
К2 |
Консультант |
20-34 |
|
К3 |
Старший консультант |
35-44 |
|
К4 |
Ведущий консультант |
45-59 |
|
К5 |
Консультант-эксперт |
60-100 |
При планировании команды проекта кроме определения ролей, ответственности и подотчетности в проекте, создается план управления обеспечением персоналом, который включает в себя определение сроков и способов набора членов команды проекта, критерии их высвобождения, рекомендации по проведению дополнительного обучения. В процессе планирования формируется концепция мотивации, определяются способы разрешения конфликтов, разрабатывается график проведения собраний команды проекта и его участников.
Оценка соответствия компетенции сотрудников стоящим перед ними задачам выполняется путем сравнения требований к квалификации для выполнения запланированных операций (см. словарь работ в разделе управления содержанием) с компетенцией сотрудников, определенной с помощью реестра навыков.
Оценку квалификации персонала рекомендуется проводить только для работ, запланированных к выполнению в текущей и последующей фазе.
В случае если есть опасения в том, что квалификация некоторых членов команды, привлекаемых для участия в проекте, может оказаться недостаточной, в рамках плана проекта следует разработать план обучения персонала. В этот план могут быть также включены программы обучения членов команды и получение ими сертификатов, наличие которых способствует успешному выполнению проекта.
Использование функции качества, изначально рассмотренной в разделе "Формирование требований проекта", рекомендуется производить в течение всего жизненного цикла проекта. С этой целью рекомендуется разработать еще три "дома качества": итерационно производные требования (требования проекта в первом доме качества, разрабатываемом на стадии планирования) перемещаются на место первичных (требования заказчика в первом доме качества) - это обеспечит корректный и непротиворечивый перевод требований заказчика (см. рис. 11.2):
Каждая из приведенных итераций (см. рис. 11.2) решает задачи одного из трех основных проектных документов: устав проекта, описание содержания и план управления. При этом противоречия, обнаруженные на 2-й, 3-й и даже 4-й итерации формирования многоуровневого дома качества, могут быть прослежены до первопричин, находящихся, допустим, на уровне требований заказчика, при помощи механизма обратной петли управления.
Рис. 11.2. Пример последовательного применения функции качества
Данный процесс, реализуемый на этапе проектирования, направлен на обеспечение непрерывного мониторинга статуса проекта и содержания продукта (результата поставки проекта), а также внесение изменений в базовый план по содержанию проекта. Все изменения, вносимые в проект, должны выполняться в соответствии с процедурами интегрированного управления изменениями проекта.
Таблица 11.11. Шаблон отчета по статусу проекта (адаптировано из [8]
|
НАЗВАНИЕ ПРОЕКТА |
|
|
. |
|
|
ИНФОРМАЦИЯ ОБ ОТЧЕТЕ |
|
|
Дата подготовки отчета |
|
|
Отчетный период |
|
|
СТОИМОСТНАЯ ХАРАКТЕРИСТИКА ПРОЕКТА |
|
|
Отклонение по стоимости на текущий момент |
[%] |
|
Стоимость проекта на текущую дату согласно плану |
|
|
Фактическая стоимость проекта |
|
|
Утвержденная сметная стоимость проекта |
|
|
Оценка стоимости проекта при завершении |
|
|
КАЛЕНДАРНАЯ ХАРАКТЕРИСТИКА ПРОЕКТА |
|
|
Отклонение от плана |
[%] |
|
СТАТУС ПРОЕКТА |
|
|
Вопросы, требующие экстренного внимания руководства |
1. [описание] 2. [описание] 3. .... |
|
Изменения содержания, стоимости и расписания проекта за отчетный период |
1. [описание] 2. [описание] 3. .... |
|
Возникшие проблемы за период и предпринятые действия по их устранению |
1. [описание] 2. [описание] 3. .... |
|
Ключевые результаты и достижения за отчетный период |
1. [описание] 2. [описание] 3. .... |
|
Ключевые результаты, запланированные на следующую неделю |
1. [описание] 2. [описание] 3. .... |
Кроме того, рекомендуется вести журнал мониторинга статуса проекта с использованием следующего шаблона (см. табл. 11. 11).
В соответствии с рекомендациями эксперта [5] к действиям по управлению требованиями относятся:
таким образом, управление требованиями проектом реализуется в соответствии с шагами, описанными в матрице управления изменениями проекта (см. соответствующий раздел).
В рамках процесса оценки потребностей в обучении пользователей необходимо произвести классификацию участников проекта в разрезе нижеприведенных групп, что позволит точно определить и оптимизировать интенсивность обучения индивидуально для каждой из групп.
1. Конечные пользователи
Это сотрудники, которые выполняют основную массу транзакций во внедряемой системе. Чаще всего именно их называют "пользователи".
2. Ключевые пользователи
Ключевые пользователи, как правило, назначаются из числа руководителей функциональных групп, они играют несколько ролей одновременно и несут ответственность за обучение на местах в своих группах.
3. Пользователи информации
Как правило, сотрудники из числа руководителей, которые принимают управленческие решения, пользуясь информацией, получаемой посредством отчетов, из информационной системы.
4. Специфические отдельные пользователи
Таблица 11.12. Факторы выбора содержания и методологии обучения
|
№ |
Фактор |
Компоненты |
|
1 |
Условия обучения |
Действительно ли важно завершить обучение? |
|
Будет ли о результатах сообщено за пределами организации (отдела/структурной единицы)? |
||
|
2 |
Доступность ресурсов |
Имеются ли в организации эксперты по предмету обучения? |
|
Имеется ли в организации опыт разработки? |
||
|
Каков доступный бюджет? |
||
|
Является ли аутсорсинг наиболее эффективным выбором с экономической точки зрения? |
||
|
3 |
Атрибуты содержания обучения |
Насколько ценен объект изучения для организации? |
|
Какой характер имеет изучаемый предмет: информационный, процедурный, поведенческий или концептуальный? |
||
|
Каким образом можно повысить интенсивность? Необходимо ли групповое взаимодействие? |
||
|
Потребуется ли часто производить обновление содержания программы обучения? |
||
|
Какова типовая продолжительность преподавания данного материала? |
||
|
4 |
Целевая группа |
Имеют ли слушатели доступ к помещениям/лабораториям? |
|
Говорят ли все слушатели на одном языке? |
||
|
Имеют ли они свободный доступ в Интернет? |
||
|
Является ли преподаваемый материал новым для слушателей? |
||
|
Каким образом будут использованы полученные знания? |
||
|
Какой стиль обучения более близок основной массе слушателей? |
||
|
На какой период времени можно отвлечь сотрудников от их основных обязанностей для прохождения обучения? |
||
|
Что мотивирует сотрудников на эффективное обучение? |
||
|
Все ли [потенциальные] слушатели живут в одном часовом поясе? |
||
|
В какой степени необходимо контролировать проводимое обучение и готовить по нему отчеты? |
||
Таблица 11.13. Формы обучения (адаптировано из [5])
|
Форма обучения |
Преимущества |
Недостатки |
|
Аудиторное обучение |
o Привычная форма o Знакомая атмосфера o Вовлечение/ высокая степень погружения слушателя o Социализация и непосредственное общение с тренером |
o Высокая стоимость o Репродуктивный процесс (допускается пассивное участие слушателей) o Трудность планирования и планирования дважды o Ограниченный охват и невозможность тиражирования |
|
Программное обеспечение учебного курса с использованием Интернета |
o Интерактивность o Удобство и простота тиражирования o Гибкость в расписании занятий o Возможность выбора настроек |
o Высокий риск отвлечения у слушателей o Зачастую требуется локализация и наличие базовых навыков работы с ПК у слушателя o Высокая стоимость разработки |
|
Программное обеспечение учебного курса на локальном носителе |
o Интерактивность o Удобство и простота тиражирования o Оценка производительности |
o Высокий риск отвлечения у слушателей o Дорогостоящая разработка и распространение |
|
Виртуальные классы, онлайн семинары (вебинары) |
o Удобство и простота тиражирования o Интерактивность для малых групп o Простота разработки и доставки |
o Репродуктивный процесс (допускается пассивное участие слушателей) o Требуется соответствующая инфраструктура для поставки |
|
Конференц-связь |
o Удобство и простота тиражирования o Простота разработки и доставки |
o Фоновый режим o Низкая интерактивность o Высокий риск отвлечения у слушателей |
|
Пособия (шаблоны и контрольные таблицы) |
o Высокая портативность o Удобство в использовании |
o Низкая интерактивность - почти полное отсутствие обратной связи o Высокий риск отвлечения у слушателей o Трудности с обновлением материала |
|
Онлайн порталы с дополнительными материалами |
o Удобство и простота обслуживания и тиражирования |
o Недостаточное внимание со стороны пользователей o Трудности с эксплуатацией и поддержкой актуальности |
|
Экспертные онлайн сообщества: форумы, группы в социальных сетях, корпоративные вики |
o Высокая интерактивность o Социализация o Удобство эксплуатацией |
o Трудности с поддержкой инфраструктуры и сохранением данных o Невозможность применения для определенных тематик и задач |
Это сотрудники, на работу которых внедрение ИТ оказывает небольшое воздействие; тем не менее, им необходимо обладать рядом навыков для выполнения специфических, узких и четко определенных задач.
5. Контролирующие лица
Это группа сотрудников, которая непосредственно не работает во внедряемой системе; в то же время, ее представители должны представлять себе принципы процессного подхода, заложенного во внедряемую интегрированную ИС.
После выделения групп участников проекта с точки зрения их дальнейшей работы во внедряемой системе необходимо также определиться с комбинацией средств обучения. Одним из подходов для решения этой задачи является метод, описанный в книге Люка Галоппена [5], - в соответствии с ним выбор учебного материала и методики зависит от факторов и компонентов, характеристика которых приведена в табл. 10.4.
С учетом результата произведенного опроса формируется комбинация видов обучения из приведенного типового списка в табл. 10.5.
Таким образом, результатом выполнения данного процесса на этапе проектирования становятся классификация различных участников проекта по группам пользователей и формирование оптимальной комбинации видов обучения.
В общем, мой друг ты одолел чтение этой статьи об планирование трудових ресурсов проекта. Работы впереди у тебя будет много. Смело пиши комментарии, развивайся и счастье окажется в твоих руках. Надеюсь, что теперь ты понял что такое планирование трудових ресурсов проекта и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Управление разработкой программных IT проектов
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Управление разработкой программных IT проектов
Термины: Управление разработкой программных IT проектов