Управление закупками в проекте

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

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

84. Структурный план проекта

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

Цели: структурирования технических и административных плановых документов проекта, контроля над ходом выполнения проекта, установления графика отчетности, структурирования проектной документации, распределения работ между участвующими в выполнении проекта фирмами и между структурными подразделениями предприятия, создания баз данных по проекту. СПП должен быть составлен так, чтобы: весь проект мог быть описан как сумма всех элементов; могло быть выполнено детальное планирование проекта; могли быть определены издержки и бюджет проекта; могли отслеживаться время, издержки и выполнение предметной области (работы); цели могли быть логическим образом увязаны с ресурсами компании; могли быть установлены процедуры контроля хода выполнения проекта; могла быть установлена ответственность за каждый элемент проекта. Структурный план проекта содержит базовую информацию для всех дальнейших частных планов – организационного, временного, материального снабжения, ресурсного, плана издержек, финансового. Структурный план проекта касается содержания проекта (что необходимо сделать?), а проектная организация касается организации работ (кто должен это делать?). Поэтому СПП нельзя рассматривать как органиграмму. Представленные в СПП иерархические уровни (ступени входимости) не идентичны уровням организационной структуры даже в том случае, когда имеется большое сходство. Должно быть выдержано правило: для каждого элемента СПП и для каждого рабочего пакета имеется ответственная единица (но только одна) в органиграмме. С другой стороны, та же единица (работник, подразделение) может быть ответственной за выполнение ряда элементов или рабочих пакетов СПП.

85. Ресурсный план проекта

Алгоритм ресурсного планирования включает: - составление перечня необходимых ресурсов; - определение объемов и сроков ресурсного обеспечения конкретных операций; - оценку доступности ресурсов; - определение источников и порядка приобретения недостающих ресурсов.

При планировании ресурсы подразделяют на возобновляемые и невозобновляемые.

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

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

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

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

86. Процессный план проекта

Планирование процесса выполнения проекта (Project Logic Evaluation – PLE) осложняется тем обстоятельством, что многие работы связаны с выполнением других работ. Процессный план содержит ин-формацию о том, какие работы связаны между собой и как их следует располагать во времени с учетом этих зависимостей, и.

может быть представлен в виде графа или таблицы. Зависимости между отдельными работами могут быть вызваны разнообразными причинами, например:

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

87. Нотация моделирования процессов IDEF0. - IDEF0 – нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Нотация IDEF0 является одной из самых популярных нотаций моделирования бизнес-процессов. Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий. Функциональный блок представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом: - верхняя сторона имеет значение "Управление"; - левая сторона имеет значение "Вход"; - правая сторона имеет значение "Выход"; - нижняя сторона имеет значение "Механизм". Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками. Декомпозиция является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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