Управление ресурсами: технический документ

Эта статья входит в нашу коллекцию "Из окопов". В нем описываются проблемы в различных аспектах управления ресурсами, а также предложения по созданию системы управления ресурсами.

Дополнительные статьи см. в статье "Из окопов".

Управление ресурсами

Управление ресурсами — это самая популярная причина, по которой организации будут переключаться с индивидуального управления проектами на корпоративное управление проектами с помощью таких систем, как Microsoft Office Project Server.

Можно подумать, что это будет означать, что у нас будет обширная книга о том, как получить самое лучшее управление ресурсами из таких систем.

Первая проблема, как и многие аспекты корпоративных систем, заключается в точном определении того, что люди означают под "управление ресурсами". В зависимости от вашей точки зрения управление ресурсами может быть различными вещами.

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

При учете ресурсов в этих системах они должны были улучшить исходные вычисления с добавлением ресурсов. Алгоритмы менялись, но целью было убедиться, что любые задержки из-за недостаточного количества определенных сделок были определены достаточно заблаговременно, чтобы нанять этих людей и получить их на работу. Мы вернемся к выравнивание ресурсов немного позже.

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

Если мы немного расширим свое мышление, мы сможем включить эти первые два определения в более широкую концепцию управления возможностями наших ресурсов. Это, на сегодняшний день, самая популярная концепция, которую нам предложено выполнить в развертывании корпоративного управления проектами. Планирование емкости ресурсов стремится ответить на несколько вопросов для лиц, принимающих решения в организации:

Могу ли я выполнить обязательства, которые я уже принял с персоналом, который у меня есть?

Если нет, то какие изменения в персонале потребуются для выполнения моих обязательств?

Если да, то какие избыточные мощности я должен взять на себя дополнительные обязательства?

Если мне предоставлен дополнительный проект, могу ли я выполнить его с помощью существующего персонала?

Если я не могу изменить свой персонал, какое влияние будет иметь новая работа, которая должна быть выполнена?

Планирование емкости ресурсов включает несколько концепций, которые необходимо реализовать в рамках процессов управления проектами. Эти решения перечислены ниже.

Чтобы приступить к проблеме планирования емкости ресурсов, мы можем начать с того, сколько работы необходимо сделать. (Если работы не требуется, нет необходимости управлять ресурсами.) Точное представление о том, сколько будет выполняться каждой задачей и кому необходимо выполнить ее, имеет решающее значение для точного анализа.

В современных средствах управления проектами, Microsoft Project, мы можем управлять потребностью в ресурсах сейчас как отделом или отдельным лицом, так и навыками. Планирование навыков включает в себя управление требованиями к ресурсам, а также управление доступностью навыков в качестве инвентаризации, что, как представляется, более эффективно, чем просто управление количеством людей, доступных в каждом отделе. В конце концов, у вас может быть отдел управления базами данных, но если в 2008 г. не хватает навыков персонала SQL Server 2008 г. и это навыки, необходимые для следующего проекта, то вам по-прежнему не хватает, когда дело доходит до реализации проекта.

Кто какие ресурсы вкладываете в назначения? Необходимо создать процесс определения определения требований к ресурсам и их решения. Следует ли начинать с запроса категории или компетенции ресурса? Должны ли вы делать запросы отдельных ресурсов в режиме "Предлагаемый", а затем кого-то в органах сделать их "Committed"? Должны ли вы иметь различные проекты с предлагаемыми ресурсами, которые хранятся отдельно? Должен ли руководитель проекта иметь возможность зафиксировать ресурсы из разных отделов или у руководителей отделов должна быть эта привилегия?

У вас есть потребности проектов в ресурсах, но какие ресурсы доступны? Кто определяет, сколько времени каждый ресурс будет доступен для работы над проектом и непроектом? Кто решает, когда можно сделать отпуск? Как определить, сколько часов сверхурочной работы можно отработать в день? Как вы будете работать с неоплаченными сверхурочные? Станет ли это время банком?

Если у вас есть как доступность, так и потребности ресурсов для проектов, сопоставление этих двух объектов должно дать вам знать, где вы переначислены, и представить задачу, касающуюся чрезмерного распределения. Следует ли приоритизировать проекты таким образом, чтобы некоторые из них получают ресурсы, а некоторые нет? Должны ли некоторые задачи быть приоритизированными, чтобы некоторые из них получить ресурсы, а некоторые нет? Следует ли использовать автоматизированное выравнивание ресурсов? Как насчет ручного перемещения задач? Кто будет иметь дело с улажением конфликта, в котором некоторые части компании ждут работы из других частей?

Этот термин обычно используется в матричной организации, где у нас есть руководители отделов, которые управляют группами ресурсов и руководителями проектов, которые управляют работой, которую должны выполнять эти ресурсы. Термин "Контракты на ресурсы" относится к переговорам между руководителями проектов и руководителями этих отделов о том, чтобы зафиксировать ресурсы на определенную работу. Это может начаться в качестве запроса от руководителя проекта о том, чтобы определенное лицо было доступно в определенный срок в течение определенного времени. Руководитель отдела может ответить встречным предложением с возможностью другого человека с похожими навыками или лица, запрашиваемого в другую дату. Затем руководитель проекта отвечает с принятием или встречным предложением и так далее, пока не будет выполнено требование ресурса.

Для некоторых организаций самым важным аспектом управления ресурсами является не планирование, а определение того, что произошло на самом деле. "Если бы вы могли просто сказать мне, что мои люди на самом деле делают с их время мы были бы гораздо более эффективными", старший исполнительный может сказать. Для этих организаций аспект разметки системы управления проектами предприятия становится наиболее значительным. Даже без интеграции в план проекта учет побок по-прежнему предоставляет огромное количество данных для управления затратами каждой задачи с точки зрения усилий. И это рисует интересную картину того, сколько времени доступно для работы над проектом и, что еще более интересно, какое время тратится, кроме работы над проектом. Когда мы можем связать коллекцию расметок обратно в план проекта, управление ресурсами может распространяться на бюджет и фактический анализ. Мы видим, сколько времени потребовалось для каждой запланированной задачи, каков пока прогресс в этой задаче, а также влияние прогресса на прогнозируемый срок выполнения этой задачи и любые другие задачи, на которые она может повлиять.

В мире строительства мегапроектов мы не так сильно переживали о связи с ресурсами. По утрам мастера будут выбирать последние новости из офиса проекта и рассказывать своим командам о том, что им нужно знать по мере начала работы. В белых воротничков высокотехнологичных типах сред проекта это совсем не так. Теперь команда проекта может быть выполнена из разных людей. Помимо план-графиков проекта и ресурсов, которые будут работать, у вас могут быть спонсоры- руководители, пользователи, клиент, субподрядчики, разработчики из источников и другие. Сейчас нередки случаи, когда команда проекта превышает не только стены вашего офиса, но и границы организации. Гораздо более значимыми становятся коммуникации в такой среде. Управление ресурсами в этом контексте может быть просто возможность эффективно сотрудничать со всеми ресурсами, вовлеченными в процесс управления проектами.

Когда мы говорим о системах управления проектами, мы обычно говорим о очень алгоритмической среде, но управление обязательствами ресурсов в рамках проекта также является важным аспектом выполнения вещей. Project руководителям команд необходимо управлять запросятными обязательствами и взятыми на себя обязательствами. Ресурс может сказать: "Я закончу это к пятнице". Это обязательство; обещание. Это может быть идеальным совпадением ожидаемой даты окончания в нашем расписании, а может и нет. Это обязательство, которое отличается от того, когда алгоритм планирования говорит, что работа должна быть сделана. Обязательства по ресурсам могут управляться в Outlook или Office SharePoint Server или на белой доске или в другом средстве обязательства, но их необходимо как-то управлять.

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

Звучит довольно просто. В конце концов, в решении Microsoft EPM есть средства для всех этих аспектов управления ресурсами. Выравнивание ресурсов, распределение ресурсов, загрузка ресурсов, планирование навыков упоминаются в базовых функциональных возможностях Project Server или даже Project стандартный или Professional. Распределение ресурсов для нескольких проектов можно сделать с мастером замены ресурсов или конструктором команды в Project Server. Отслеживание ресурсов можно сделать с помощью таблицы в Project Server. Контракты на ресурсы не имеют много интерфейса по умолчанию, но вся идея предлагаемых и совершенных ресурсов находится в этой области, поэтому более надежный интерфейс для работы с запросами ресурсов можно сделать с помощью веб-формы с Office SharePoint Server и связать в функциональность непосредственно. Даже Sub-Contracting ресурсов можно было бы решить с помощью функций Office SharePoint Server.

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

Существует фундаментальная проблема, когда мы пытаемся применить алгоритм выравнивания ресурсов к высококвалифицированным группам ресурсов. Чтобы понять это, стоит вернуться к тому, о чем думали оригинальные дизайнеры, когда создавались алгоритмы выравнивания ресурсов. Я обещал вернуться к выравнивание ресурсов и даже критический анализ цепочки, и именно поэтому.

Когда мы думаем о исходных двигателях выравнивания ресурсов, они были разработаны для инженерного контекста. Первые средства планирования проектов были написаны для тяжелых инженерных и строительных проектов, в которых расчеты будут делаться по одному проекту одновременно. Действительно, для доставки одного проекта могла быть создана вся организация. Оригинальные коммерческие средства ориентированы на оборонную и нефтегазовую отрасли, которые могли бы использовать большой объем данных, которыми эти средства могли управлять. Но когда мы смотрим на ресурсы для таких проектов, мы всегда думаем о универсальных ресурсах.

Планирование ресурсов для такого проекта неизбежно происходит с помощью навыков. Планиры проектов думают о том, сколько машиностроителей, электриков и pipefitters им может понадобиться. Алгоритмы выравнивания ресурсов идеально подходят для этого вопроса. У нас есть ряд ресурсов, мы выравниваем задачи, и число штатных сотрудников может изменяться в сторону вверх или вниз по мере необходимости. Когда мы думаем об этом для значительного числа одного и того же типа взаимозаменяемого ресурса, алгоритм работает довольно хорошо.

Современное управление проектами расширило концепции, изначально созданные для мегапроектов, с большим количеством взаимозаменяемых ресурсов и применило их до индивидуального уровня. Алгоритм по-прежнему работает, по крайней мере в теории, и он точно работает в демонстрации, потому что мы только когда-либо показывать один ресурс одновременно.

Рассмотрим этот пример.

У меня есть простой проект здесь в Project профессиональный 2007. Я начал проект с вехи и добавил две задачи, которые должны начаться сразу после завершения вехи. Как только я назначаю Крису обе задачи, у меня возникает проблема выравнивания ресурсов. Как видно на разделенных экранах, Крису выделяется вдвое больше его доступности, что имеет смысл.

Теперь давайте выровном уровне проекта с Project ресурсов в алгоритме выравнивания ресурсов:

Опять же, все идеально. Задачи Криса были распространены в течение двух недель, а не один, показывая, как одна из задач должна быть отложена на вторую неделю, чтобы получить все это выполнено. Кроме того, Показано, что Крис непрерывно работает с одной недели до второй недели.

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

Теперь у меня есть два человека, работающих одновременно. Крис возвращается к ситуации чрезмерного выделения (вы можете увидеть обе его задачи в неделю, и мы добавили три задачи для Джона, который начнется одновременно. Однако задачи Джона уже выровна, так как для них есть последовательность. Если мы смотрим только на ситуацию Джона, это выглядит нормально. John is working continuously from week one into week two, but what happens when we apply the resource leveling algorithm now?

Project время Криса как раз так, как это было в первый раз, и работа Криса непрерывна с недели 1 до 2 недели. Джон, однако, будет иметь разрыв в течение полной недели в своей работе, как он ждет Криса, чтобы завершить свою вторую задачу. Маловероятно, что мы хотим, чтобы Джон читал газету и простаивал в своей кабине в течение всей недели, поэтому теперь он будет до руководителя Джона и Криса (ы) вручную управлять тем, как они должны планировать свое время.

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

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

Это также одна из основных причин, по которой у нас нет аналитических средств, таких как Project в систему обязательств по ресурсам, например Outlook. Outlook по своей сути можно считать системой личных обязательств. Вы каждый день Outlook в своей Outlook. Вы обещаете, что будете на встрече на следующей неделе в 14:00. (Что кто-то может быть самим собой.) Вы обещаете, что выполните задачу к этому вторнику. Мы смотрим на Outlook, чтобы узнать, какие задачи и встречи нам нужно выполнить, а затем использовать функции связи системы для ответа другим о обязательствах, которые мы выполняем или запрашиваем.

Imagine теперь мы интегрируем это с Project, которая по своей сути является аналитической системой. Перемещение действий Project или Project Server в Outlook и ирисовка прогресса по ним — это одно. Что делать, если все Outlook задачи были интегрированы обратно в расписание? На следующей неделе я могу записаться на прием к стоматологу. Должен ли я теперь позволять воздействию этого четырехчасового разрыва в моей доступности влиять на каждую задачу, которую я запланивал в будущем? Следует ли выполнять все задачи через четыре часа? Как быть со всеми расписаниями всех людей, с которыми я взаимодействую, или с задачами которых зависит моя четырехчасовая задержка? Должна ли вся компания теперь получать сообщения электронной почты с сообщением о том, что их расписание было отжато через четыре часа? Но подождите, я всего лишь один человек. Что происходит, если обязательства Outlook влияют на каждую задачу каждого человека в компании? Короче говоря, у нас будет хаос.

Если мы хотим интегрировать обязательства по ресурсам или средства связи с ресурсами, например Outlook, с инструментом планирования емкости ресурсов, например Project или Project Server, нам необходимо согласовать философские различия между этими двумя парадигмами. Когда была разработана ссылка Project server на Outlook, это стало частью мышления. Outlook будет включено получение задач из Project и интеграция этих задач в Outlook или список задач. Не было разрешено выполнять задачи Outlook Project Server.

Если вы сделали это так далеко, то вы можете надеяться, что у меня есть несколько советов по созданию управления ресурсами, и у меня есть несколько предложений.

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

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

Если планирование емкости ресурсов является вашей проблемой, у меня есть идея для вас, что не предлагается очень часто. В любой высокотехнологичной организации планирование навыков на индивидуальном уровне очень распространено, так как многие люди имеют уникальную коллекцию навыков и знаний, что делает их особенно подходящими для определенных видов работы. Если это ваша ситуация, рассмотрите возможность создания "ключевого ресурса Project". По моему опыту, ключевые ресурсы в организации составляют менее пяти процентов от общего числа ресурсов. Эти ключевые ресурсы — это люди, необходимые для каждого проекта. Они имеют такое сочетание навыков и знаний, которые не находятся в других местах, и успешные руководители проектов знают, чтобы убедиться в том, чтобы получить один из этих ключевых ресурсов на свои проекты, если они хотят добиться успеха.

Ключевым ресурсом Project список всех задач, поставленных только этим людям. Вы бы выравнивали уровень ресурсов их работы и разрешали запланить все остальные ресурсы вокруг них, как бы они ни были руководителями команд. Это может быть реализовано практически мгновенно и занимает относительно небольшое количество усилий. Организации, которые пытались это найти, часто устраняют большую часть проблемы выравнивания ресурсов без культурных проблем и задач по улучшению процесса процесса, который должен включать всех.

Кроме того, стоит думать о том, что ваше решение является более обширным, чем просто Project Server, как это делает Project Microsoft. "Решение Microsoft EPM", в конце концов, является стеком технологий. Если учесть все различные аспекты управления ресурсами, то Windows SharePoint Services, Windows рабочий процесс, Office SharePoint Server (для форм) SQL Server все они становятся векторами, необходимыми для создания среды, адаптированной к тому, что необходимо для вашего организации.

Об авторе

Крис Вандерслуис является президентом и основателем канадской компании HMS Software, сертифицированного партнером Microsoft. Он имеет степень по экономике в Университете McGill и более 30-летний опыт автоматизации систем управления проектами. Он является давним членом Института управления Project (PMI) и помог найти главы Группы Microsoft Project пользователей (MPUG) в Монреале, Торонто и Квебеке. Публикации, для которых Крис написал: Fortune, Heavy Construction News, Computing Canada magazine и PMI's PMNetwork, и он является регулярным обозревателем для Project Times. Он преподает Project управления в Университете McGill и часто выступает на функциях ассоциации управления проектами в Северной Америке и по всему миру. HMS Software является издателем системы хронометража проекта TimeControl и с 1995 Microsoft Project партнером по решению.