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

Если для западных менеджеров приоритетными являются психологические аспекты управления и искусство выстраивания межличностных отношений в проекте, то их отечественные коллеги предпочитают процедурный подход. Это действительно так (по крайней мере, в отношении российских менеджеров) и означает, что работа в рамках определенных ограничений и стандартов, является для наших менеджеров не просто привычной (вспомним хотя бы советские ГОСТы), но и вполне комфортной. А что тогда говорить о руководстве компании, для которого наличие и исполнение таких стандартов означает гарантированный уровень качества выполнения проектов?

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

И, наконец, упомянем, тот факт, что практика создания собственных методик и руководств по управлению проектами широко распространена в крупнейших западных компаниях, таких как Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP AG, Siemens и др.

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

Каково же конкретное наполнение такого стандарта? Как сделать стандарт предприятия работающим инструментом управления проектами? Какие информационные технологии могут использоваться для поддержки стандарта?

Этим и другим смежным вопросам посвящён доклад.

1. Общие соображения по созданию стандарта. Специализация и детализация.

Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют "рамочными"). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI), признаваемый многими международным стандартом де-факто, и стандарт ISO 10006:1997, придавший ряду наиболее важных положений PMBoK статус стандарта де-юре. Смысл и содержание перехода от рамочных стандартов (какими, являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия состоит в их специализации и детализации.

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

Проекты компании могут относиться к различным профессиональным областям деятельности (юридическая, финансовая, ИТ, строительная, маркетинговая и т.д.), иметь различную сложность с точки зрения решаемых задач, различный масштаб с точки зрения привлекаемых ресурсов и предполагаемого результата. Могут выделяться некоторые категории проектов, специфические с точки зрения конкретных отраслей. Например, в стандарте компании Enron, специализировавшейся в своё время в области электроэнергетики, отдельно рассматривались международные (overseas) проекты, как предъявляющие особые требования к законодательной базе, к персоналу, оборудованию, экономической инфраструктуре, логистике и т.д.

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

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

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

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

Выбранные элементарные процессы образуют процедуры управления проектами, которые могут быть построены по "осевому" принципу (здесь имеются в виду абсцисса, ордината и аппликата, обозначенные на рис. 1).

Собственно описание этих процедур и составляет основной объем стандарта. А если быть более точным, под стандартом предприятия мы понимаем совокупность документов, объясняющих или предписывающих как, в какой последовательности, в какие сроки, с использованием каких шаблонов нужно выполнять те или иные действия в процессе управления проектами. Количество этих документов зависит от степени детализации стандарта и может быть достаточно велико (от десятков до сотен документов). На рис. 2 они представлены в виде ступенчатой пирамиды (цилиндрического зиккурата), которая обычно выстраивается сверху вниз по мере пробуждения аппетита у тех, кто организует и регламентирует работы на предприятии, и соответствующего ему развития стандарта.

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

Рис. 1. Пространство процессов управления

Рис. 2. Структура стандарта управления проектами

2. Классификация проектов как первый этап создания стандарта

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

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

Это особенно важно для предприятий, реализующих комплексные проекты, захватывающие различные предметные области. Характерным примером, в котором в равной степени очевидны и необходимость привлечения "универсального" руководителя проекта, и пути снижения стоимости его "содержания", является проект создания филиала банка. Такой проект включает целый ряд взаимосвязанных и, вместе с тем, относительно независимых подпроектов: юридический, строительный, технологический, ИТ, рекрутинговый, маркетинговый и т. д. В крупных банках филиалы создаются десятками. После одного-двух таких проектов опыт их реализации может оказаться достаточным для того, чтобы сформировать для каждого вида проектов (подпроектов) типовые цели и результаты, типовые календарный и ресурсный планы и бюджет, определить известные риски и эффективные стратегии работы с ними и т. д.

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

Что должно быть отражено в Плане управления проектом

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

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

Управление отклонениями - процедуры работы с рисками, с возникающими проблемами и изменениями, форм соответствующих проектных документов

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

Контроль и отчетность - регламент проведения мероприятий по анализу состояния проекта, соответствующие формы отчетности.

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

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

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

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

Классификация по масштабности проекта позволяет специализировать разделы Организационная структура , Управление отклонениями, Обеспечение качества . Для построения этой классификации могут использоваться различные основания - территориальная разбросанность, как это принято в Enron Corp., или стоимость проекта (IBM), может быть, какие-то другие основания и их комбинации.

Классификация по форме оплаты и, следовательно, учета работ позволяет специализировать Контроль и отчетность , Управление проектной документацией на основании таких форм контрактов как "Время и материалы" и "Фиксированная цена".

Таким образом, можно вести речь, например, о шаблоне "План управления проектом создания концепции (продукт ) информационной системы (предметная область ) стоимостью свыше $ 100 тыс. (масштабность ) с контрактом в форме "время и материалы" (форма оплаты и учета работ )", как о макрошаблоне, получаемом простой сборкой из нескольких более мелких (микро) шаблонов отдельных разделов Плана. Кроме того, в макрошаблон должны быть включены и некоторые дополнительные разделы, которые не могут быть определены на микроуровне (такие, например, как "Сроки работ по этапам"). Микрошаблоны могут быть глубоко специализированными - насколько это позволяет соответствующая классификация и накопленный на предприятии опыт.

Рассмотренные выше примеры классификаций проектов специально подобраны нами для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов. Однако в реальной жизни встречаются и другие ситуации. Например, в IBM принята классификация проектов по сложности (комплексности) . В соответствии с этой классификацией проекты делятся на обычный бизнес (Business as Usual - BaU), стандартные проекты системной интеграции и сложные проекты системной интеграции. Причем именно эта классификация является определяющей для структуры и содержания Плана управления проектом. При этом другие классификации сохраняют свое значение для формирования отдельных разделов Плана.

3. План управления проектом

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

Покажем, как могут выглядеть некоторые разделы специализированного шаблона Плана управления проектом. Используем для этого пример проекта создания филиала банка, приведенный в предыдущем разделе. Рассмотрим подпроект создания ИТ-инфраструктуры филиала банка.

При построении специализированного микрошаблона "Содержание и границы проекта" мы использовали рекомендации PMBoK PMI (Табл. 1).

В этом шаблоне остается менять только названия программного обеспечения и сроки выполнения этапов работ.

Описание количественных критериев, которые должны быть удовлетворены, чтобы проект считался успешным

Срок доставки оборудования и программного обеспечения в Москву не должен превышать ХХ дней.

Срок наладки оборудования и программного обеспечения в Москве не должен превышать YY дней.

Срок транспортировки оборудования и программного обеспечения в филиал банка не должен превышать ZZ дней.

Срок установки и наладки оборудования и программного обеспечения в филиале не должен превышать WW дней.

Сопоставив приведенное в примере содержание разделов Продукт проекта и Результаты проекта , можно заметить, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании Плана (а, следовательно, и при формировании шаблона Плана) часто используют структуру декомпозиции работ (WBS – Work Breakdown Structure), а многие ведущие компании включают в свои методологии и стандарты типовые WBS как в явном виде (Andersen Consulting), так и неявно (IBM).

Структура декомпозиции работ

Провести декомпозицию и составить структуру декомпозиции работ (WBS – Work Breakdown Structure) по утверждению некоторых авторов очень легко: "Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации" (Цитируем по статье М. Ньюэлла "Структура декомпозиции работ" в мартовском номере журнала "Директор информационной службы" за 2001 г.).

На самом деле, все не так однозначно, причем речь пойдет не только о сложностях создания WBS, но и об открывающихся возможностях. Рассмотрим проблему на примере проекта создания информационной системы (ИС).

На стадии инициализации проекта руководитель проекта должен ответить на целый ряд вопросов (на самом деле их, конечно, гораздо больше, но мы ограничимся этими):

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

На какие же подпроекты следует разбить исходный проект? Что будет удобнее видеть на первом уровне декомпозиции - компоненты ИС (программные, технические, информационные) или технологические этапы (концепция, техническое задание, проектирование и т. д.)? А может быть удобнее сгруппировать работы по исполнителям или по заказчикам?

Например, если работы проекта выполняются в интересах различных Заказчиков и, в то же время, финансируются различными Инвесторами (см. Рис. 3) декомпозиция может выполняться либо по содержательному признаку отнесения работ к проектам, либо по формальному признаку отнесения работ к договорам финансирования. Другой случай - фиксация в структуре работ участия субподрядчиков. Тогда для этапа календарного плана проекта формально выделяются группы работ, выполняемые основным исполнителем (Подрядчиком) и другими исполнителями (Субподрядчиками). Такую декомпозицию целесообразно применять, если за субподрядчиками закреплены крупные логически взаимосвязанные блоки работ, относительно независимые от других работ проекта.

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

А следовательно, первое, что должно быть отражено в специализированном шаблоне WBS, это какие альтернативные взгляды на структуру декомпозиции работ должны поддерживаться в проекте (взгляд руководителя проекта, взгляд куратора, взгляд инвестора и т.д.).

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

План управления проектом и рамочные стандарты

Кому-то может показаться, что создать шаблон плана управления проектом достаточно просто, надо только иметь под рукой "рамочные" стандарты, например PMBoK и ISO 10006 и разбираться в предметной области. На самом деле, это совсем не так. В большинстве случаев рамочный стандарт дает лишь понятийный аппарат и общие методологические принципы. Более того, дело осложняется еще и тем, что необходимая информация в самих рамочных стандартах "рассыпана" по разным разделам и ее не так-то просто "собрать, выстроить, и привести к общему знаменателю".

Проиллюстрируем это на примере не самого сложного раздела плана "Организационная структура проекта". В PMBoK необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) - разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации не достаточно!

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

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

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

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

Однако, уже планируя проект, мы предполагаем, что не все получится именно так, как запланировано. И реальное исполнение проекта, как правило, подтверждает эти опасения. Возникающие несовпадения первоначального согласованного и зафиксированного представления о проекте (project baseline) и того, что получается в действительности, и называются обычно отклонениями. Понимаемый в этом смысле термин "отклонения" эквивалентен термину "deviations", используемому в англоязычной литературе.

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

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

Отметим, что соображения, представленные в этом разделе, не являются какими-то отвлеченными рассуждениями и основаны на материалах действующего стандарта управления проектами компании IBS. Мы благодарны компании за предоставленную возможность использования этих материалов, и коллективу разработчиков (Илья Виноградов, Мария Чукова) за возможность использования этих материалов.

Сценарии управления отклонениями

Управление отклонениями в основном сводится к борьбе с неприятностями, которая в общем случае может включать три стадии:

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

Управление проблемами . Неприятности наступили и необходимо выяснить их происхождение, степень влияния на проект, способы преодоления. Цель этой стадии - обеспечить проекту возможность идти так, как запланировано.

Управление изменениями . Неприятности оказались достаточно серьезными, и справиться с ними без ущерба для проекта не удалось. Цель этого этапа – то, что у финансистов называется "зафиксировать убытки" – модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.

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

События в проекте, связанные с отклонениями, могут развиваться по различным сценариям, некоторые из которых представлены на Рис. 4 .

Рис. 4. Общая схема управления отклонениями

Полному циклу управления отклонениями соответствует первый сценарий, при котором,

В ходе планирования проекта был идентифицирован риск, но работа с ним не привела к желаемому результату,

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

И все это в результате привело к необходимости внесения изменений в план проекта.

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

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

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

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

Самое простое, и вместе с тем необходимое, что должно быть отражено в стандарте - формальная сторона управления рисками, а именно:

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

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

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

Табл. 2. Матрица степени угрозы риска

"Цена деления" как на вспомогательных (вероятность и влияние) так и на основной шкале (степень угрозы) должна определяться из сугубо практических соображений - достижима ли та или иная точность и может ли она быть использована.

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

Управление проблемами

Прежде всего, поясним, что мы называем проблемами и почему проблемами можно (и нужно) управлять.

В ходе реальной работы по созданию и внедрению стандарта управления проектами на предприятии авторам пришлось столкнуться с тем, что словосочетание "управление проблемами" вызывает недоумение у коллег, не имевших опыта знакомства с англоязычными стандартами управления проектами. Многим кажутся более привычными укоренившиеся в русскоязычной литературе термины «решение» или «разрешение проблем», которые соответствуют определениям «problem solving» или «problem resolution», принятым в упоминавшихся выше так называемых "рамочных" стандартах.

Авторы в этом вопросе предпочитают следовать духу и букве таких стандартов управления проектами как MITP/PMM/WISDDM корпорации IBM, в которых этот процесс называется "problems/issues management", что в русском переводе лучше всего, на наш взгляд, выглядит именно как "управление проблемами".

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

Обычно проблемы делят на две категории - на проблемы, которые могут быть решены в месте возникновения, то есть на уровне управления проектом - problems, и эскалируемые проблемы - issues, которые для их разрешения требуется поднять на верхние уровни управления, в том числе, внешние по отношению к проекту.

В стандарте должна быть отражена формальная сторона управления проблемами:

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

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

Табл. 2. Матрица приоритетов решения проблем

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

Управление изменениями

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

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

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

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

• Плановые потери (учтены в плане управления проектом).
• Допустимые потери (незначительные незапланированные затраты).
• Нежелательные потери (значительные незапланированные затраты).
• Недопустимые потери (незапланированные затраты, которые являются неприемлемыми для одного или нескольких участников проекта).

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

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

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

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

На диаграмме могут быть показаны и желаемая, и возможные альтернативные стратегия измерений (см. Рис. 6). Теперь для того, чтобы получить возможность сравнивать альтернативные варианты не только качественно, но и количественно, осталось только разработать метрики для каждой из осей. И тогда стратегию можно будет оценивать, например, площадью соответствующего треугольника.

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

Рис. 5. Области потерь

Рис. 6. Стратегии изменений в проекте

5. Организационные структуры в проектах

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

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

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

Начальник отдела и руководитель проекта

Административное управление на предприятии реализуется через систему менеджмента, ключевым звеном которого являются менеджеры среднего звена – начальники подразделений, в непосредственном подчинении которых находятся сотрудники предприятий. На проектно-ориентированных предприятиях смысл деятельности начальника подразделения состоит в том, чтобы «раздать», а точнее «продать» всех своих сотрудников в проекты.

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

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

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

Часто возникает путаница, какие функции относятся к компетенции начальника подразделения, а какие – к компетенции руководителя проекта. Особенно это характерно для случаев когда «руководитель проекта» - не должность в штатном расписании предприятия, а только проектная роль, которую может исполнять, в том числе, и начальник подразделения. В Табл. 3 приведено несколько примеров, иллюстрирующих эти различия в некоторых областях, где административное и проектное управление имеют точки соприкосновения.

Табл. 3. Разделение ответственности при административном управлении и управлении проектами

Исполнитель

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

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

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

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

Команда проекта

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

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

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

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

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

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

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

Рис. 7. Схема формирования команды проекта

6. Обеспечение качества и служба управления проектами

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

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

Планирование и контроль качества в проекте

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

Планирование качества осуществляется как часть процесса планирования проекта в целом. Результаты планирования качества проекта (план по качеству проекта) должны отражаться в Плане управления проектом.

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

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

Аудит проекта - проверка соответствия формализованной организационной деятельности по реализации проекта принятым стандартам управления проектами. Аудит производится в определенные моменты выполнения проекта с целью контроля исполнения процедур управления проектом, определенных в стандарте, и правильности оформления документов проекта.

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

Мониторинг проекта - регулярно выполняемая оценка состояния проекта, учитывающая различные виды деятельности в рамках проекта. Целью мониторинга является предоставление руководству предприятия оперативной агрегированной информации о реализации проекта, достаточной для принятия ключевых решений по проекту.

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

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

Рис. 8. Диаграмма текущего статуса управления проектом

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

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

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

Служба управления качеством и Служба управления проектами

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

К таким службам могут быть отнесены Служба управления качеством и Служба управления проектами. Место этих служб в организационной структуре предприятия и их функции показаны на Рис. 9.

Рис. 9. Структура и функции служб, отвечающих за качество исполнения проектов

Служба управления качеством в части управления проектами обеспечивает:

• Интеграцию стандарта управления проектами в общую систему стандартов компании.
• Контроль качества управления проектами в форме проведения аудиторских проверок выполняющихся проектов с целью проверки соблюдения корпоративных стандартов управления проектами.

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

Важное место в работе Службы управления проектами должна занимать разработка методологии управления проектами, в том числе:

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

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

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

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

7. Тактика и стратегия внедрения стандарта управления проектами

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

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

Основные этапы создания стандарта управления проектами

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

Работая в области консалтинга, авторы отлично представляют то раздражение, которое могут вызвать у некоторой категории уважаемых коллег слова «концепция» и «методика». И, тем не менее, рискнем сказать, что предпочтительным путем создания стандарта является путь последовательной детализации, включающий, в том числе, этапы разработки концепции и методики управления проектами предприятия (см. Ошибка! Источник ссылки не найден. ).

Рис. 10 . Этапы создания стандарта управления проектами

Концепция управления проектами является основополагающим документом системы управления проектами (СУП) предприятия, обосновывающим деловую необходимость создания СУП (включая экономическую эффективность внедрения), определяющим ее основные параметры и результаты, стратегию реализации и развития, объем автоматизации и используемые информационные технологии.

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

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

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

Стандарт управления проектами в общем контексте управления предприятием

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

Рис. 11. Стандарт управления проектами в системе управления предприятием

Стандарт управления проектами неразрывно связан с системой качества и должен быть гармонизирован со стандартами качества, применяемыми на предприятии. В оптимальном варианте стандарт управления проектами должен создаваться, как составная часть системы качества предприятия и может стать основой для подготовки предприятия, его подразделений и сотрудников к сертификации по стандарту ISO 9000 и по управлению проектами.

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

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

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

Информационные технологии в управлении проектами

Здесь мы выделим два основных направления – автоматизация стандарта управления проектами и автоматизация функций управления проектами.

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

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

В силу этого одним из перспективных подходов является организация стандарта как базы знаний, которая обеспечивает все необходимые сервисы по обновлению и поиску документов, по организации взаимосвязей между документами, перекрестных ссылок и т.д. Хотя известны примеры и другого подхода, когда для поддержания стандарта создается специализированная информационная среда (Andersen Consulting).

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

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

К основным областям деятельности по управлению проектами, подлежащим в той или иной степени автоматизации, мы относим:

• Собственно управление проектами, которое в узком смысле обычно понимается как календарно-ресурсное планирование.
• Формирование и ведение бюджета проекта.
• Управление документами, как управленческими, так и являющимися результатами выполнения проекта.
• Управление деловыми процессами в проектах, включая процессы согласования документов.

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

Автоматизация управления проектами не является темой этого доклада. Поэтому здесь мы ограничимся констатацией того, что средства автоматизации управления проектами необходимо связывать с другими информационными системами предприятия (например, с системой управления персоналом, с ERP-системой и т.д.). А это, в свою очередь, приведет к необходимости установления интерфейсов между базовыми пакетами прикладных программ, использованных для создания связываемых элементов интегрированной системы предприятия. . В последнее время модули управления проектами всё чаще становятся частью таких прикладных систем как ERP , например модуль Project System в SAP R /3 и CRM , например, модуль Eventix Engagement в SalesLogix .

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

8. Глоссарий управления проектами

Начнем этот раздел с рассказа об одном забавном эпизоде. Однажды, в нашей компании проходили практику студенты-дипломники, специализирующиеся по управлению проектами. Выдавая им задание, руководитель практики (один из авторов этого доклада) попросил описать scope проекта (он так и сказал – скоуп). ”А что такое scope?” – осторожно уточнила одна девушка. ”О, scope – это…” – ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. “Понятно, - грустно сказала девушка. – Нам в институте также объясняли”.

Ситуация очень характерная и довольно опасная. Есть некий термин, употребляемый в англоязычных источниках и не имеющий очевидного и однозначного перевода на русский язык в контексте управления проектами. На профессиональном жаргоне мы привыкли пользоваться этим термином на языке оригинала. Действительно, гораздо удобнее сказать scope , чем какое-нибудь достаточно громоздкое “содержание и границы”. Если кому-то непонятно, то всегда можно объяснить, хотя бы с помощью жестов. А приводит все это к тому, что некоторое время спустя точного значения термина никто уже не помнит, каждый трактует его по-своему, и при этом все думают, что понимают друг друга!

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

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

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

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

Краткий глоссарий

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

Проект - уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам [ ISO].

Проект – целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК].

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

Управление проектом включает планирование, организацию, мониторинг и контроль всех аспектов проекта в ходе непрерывного процесса достижения его целей [ ISO].

Управление проектом – процесс применения знаний, навыков, методов и средств и технологий к проектной деятельности с целью достижения или превышения ожиданий участников проекта [ PMBOK].

План управления проектом (Project Management Plan) - основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах – Мастер-план проекта (Project Master Plan) (УП).

Устав Проекта ( Project Charter) - документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта [ PMBOK].

Определение Проекта ( Project Definition Report) - документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чём его необходимость; что должно быть сделано; как, когда, и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК].

Базис (Project Baseline) - Основополагающие параметры и фиксирующие их согласованное понимание всеми участниками документы проекта – «точка опоры» для всего последующего развития проекта.

Базовый план (Baseline) - Первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта - стоимости, расписанию и т.д. [ОУП].

Предметная область ( Scope) – совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта [ PMBOK].

Цели ( Scope) - совокупность продуктов и услуг, намеченных к производству в проекте [ОУП].

Ключевые вехи проекта (Project Milestones) - ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule).

Контрольное событие - важное событие проекта, обычно связанное с достижением важнейших результатов [ОУП].

Другие варианты – ключевое событие [УП], контрольная точка [УП].

Структура декомпозиции работ (Work Breakdown Structure), СДР (WBS) - представление проекта, в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

Структурная декомпозиция работ - иерархическая структуризация работ проекта, ориентированная на основные результаты проекта, определяющие его предметную область. Каждый нижестоящий уровень структуры представляет собой детализацию элемента высшего уровня проекта. Элементом проекта может быть как продукт, услуга, так и пакет работ или работа [НТК].

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

Структура разбиения работ – иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня пакеты детальных работ [УП],

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

Отклонение ( Deviation) – выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает[ QMPP].

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

Риск – потенциальная, численно измеримая возможность неблагоприятных ситуаций связанных с ними последствий в виде потерь, ущерба, убытков [УП].

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

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

Проблемные ситуации ( Problem situations) – возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК].

Решение проблем ( Problem Solving) – определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК].

Изменения проекта (Project Changes) - модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, используемых ресурсов, управленческих и технологических процессов и т.п.

Изменения – Увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП].

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

Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта [НТК].

Куратор проекта (Sponsor) - лицо, отвечающее перед руководством предприятия за успех проекта в целом и имеющее полномочия для решения ресурсных и других проблем, эскалированых руководителем проекта.

Спонсор проекта – отдельный человек или организация, для которых проект предпринят и которые в наибольшей степени принимают на себя проектный риск [ BS2].

Руководитель проекта (Project manager) - менеджер, отвечающий за успешную реализацию проекта, взаимодействие с Заказчиком, субподрядчиками и подразделениями Компании, организацию подготовки и предоставление отчетности по проекту.

Менеджер проекта - лицо, ответственное за управление проектом [ PMBOK].

Бюджет проекта (Project budget) - Утвержденное запланированное распределение финансовых средств проекта по различным основаниям: по статьям затрат; по временным периодам, по участникам проекта; решаемым задачам, по компонентам ожидаемых результатов; по элементам организационной структуры проекта и т. п.

Бюджет проекта – сметная стоимость, распределенная по периодам выполнения проекта [НТК].

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

Участники проекта – физические лица и организации, которые непосредственно вовлечены в проект или чьи интересы могут быть затронуты при осуществлении проекта [ PMBOK].

9. Дополнительные преимущества от внедрения стандарта.

Стандарт управления проектами и человеческие ресурсы

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

Стандарт не заменит этой литературы, но роль его в целенаправленном обучении персонала компании может быть весьма значительной. Здесь, на наш взгляд, будет уместной следующая параллель. В части процессов управления проектами стандарт предприятия специализирует и детализирует требования рамочных стандартов (таких как ISO 10006 или PMBOK PMI). Точно также в части квалификации управленческого персонала стандарт предприятия специализирует и детализирует требования нормативных документов рамочного характера в этой области (таких как ICB или НТК).

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

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

Стандарт управления проектами и уровень зрелости процессов управления

Сам факт использования стандарта управления проектами свидетельствует о том, что на предприятии достигнут определенный уровень зрелости процессов управления. Для того чтобы измерить этот уровень и определить направления дальнейшего развития могут применяться различные способы. Одним из популярных подходов является использование моделей зрелости, широко известна модель Capability Maturity Model (CMM), применяемая для оценки зрелости организаций, разрабатывающих программное обеспечение.

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

В качестве другого примера приведем пятиуровневую модель (PM) 2 – Project Management Process Maturity Model .

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

Второй уровень зрелости (уровень индивидуального планирования проектов) соответствует применению в организации отдельных неформализованных и некомплектных процедур управления проектами. Руководителями проектов процессы управления проектами частично признаются и контролируются. Однако в каждом конкретном проекте планирование и управление зависит от индивидуального подхода его руководителя.

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

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

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

На наш взгляд, какая бы ни была принята модель зрелости процессов управления проектами, стандарт управления проектами должен играть в ней ключевую роль. Так, достижение третьего и более высоких уровней зрелости по модели (PM) 2 просто немыслимо без стандарта управления проектами. И именно стандарт является формальным отражением достигнутого уровня зрелости процессов управления проектами.

Стандарт управления проектами и маркетинг

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

Очень часто для того, чтобы получить выгодный контракт, компания должна показать, что знает, как управлять проектами и умеет это делать. Собственно, практически в любом крупном тендере на разработку информационных систем обязательно содержатся требования в части управления проектами. Иногда эти требования носят конкретный характер, например, «Как будет организована проектная группа с учетом участия в проекте многочисленных сторон? Каким образом будут поддерживаться отношения с различными партнерами?». Чаще они формулируются в самом общем виде: «Предоставьте информацию по процессам управления Вашей компании, позволяющим отслеживать и контролировать все аспекты, относящиеся к проекту, включая …».

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

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

10. Литература:

1 Михеев В.Н., Товб А.С. Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов. В сб. Трудов 2-ой Всероссийской практической конференции «Стандарты в проектах современных информационных систем», М., 2002. – с.33-37.

2 Товб А.С. Ципес Г.Л. Метод и опыт создания предприятия по управлению ИТ-проектами. В сб. Трудов 2-ой Всероссийской практической конференции «Стандарты в проектах современных информационных систем», М., 2002. – с.42-47.

3 Товб А.С. Ципес Г.Л. Заметки по управлению проектами. Стандарт управления проектами уровня предприятия. «Директор информационной службы» №№ 1-6, 2001 и №№ 1-6, 2002.

4 «Директор информационной службы» №5, 2001.

5 C. William Ibbs, Young-Hoon Kwak. The benefits of Project Management: financial and organizational rewards to corporations. - Project Management Institute Education Foundation, 1997

11. Источники, по которым цитируются определения:

Британский стандартBS 6079-2:2000 Project management Part 2 Vocabulary. (перевод авт.).

ISO/TR 10006: 1997 (E). Quality Management – Guidelines to quality in project management (используется перевод Г.Е. Герасимовой).

Wideman Comparative Glossary of Project Management Terms. PMForum, 2000 (www.maxwideman.com).

A Guide to the Project Management Body of Knowledge. PMI Standards Committee.1996 Edition (используется перевод М. Грашиной).

Quality Management for Projects and Programs, Lew Ireland, Project Management Institute , Newtown Square, PA, 1991. (Цитируется по , перевод авт.)

[НТК] Основы Профессиональных Знаний и Национальные Требования к Компетентности специалистов по управлению проектами. Под ред. В.И. Воропаева, 2001.

[ОУП] Основы управления проектами. В.И. Либерзон.

[УП] Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001.

[УПП] Управление программами и проектами. 17-модульная программа для менеджеров «Управление развитием организации». Модуль 8. М.Л. Разу, В.И. Воропаев и другие, 1999. Ссылки

В отличии от PM BoK PMI в методологии MITP(PMM) IBM термин Project objectives означает задачи проекта, решение которых, т.е. достижение соответствующих подцелей может быть оценено по количественным критериям.

Например, в различных материалах, основанных на методологии MITP компании IBM, проектные риски не всегда включаются в состав отклонений.

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

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

Качественное управление проектами возможно только при опоре на соответствующие стандарты. На первый взгляд понятия «проект» и «стандарт» могут показаться трудно совместимыми. Ведь даже в определении проекта включается понятие об его уникальности, неповторяемости целей, условий реализации, результатов проектов. Поскольку это действительно так, что же можно стандартизовать в управлении проектами? А если и можно, то нужно ли? Не будет ли это мешать, сковывать инициативу, навязывать неоптимальные решения?

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

С другой стороны, крупные западные компании (Siemens, IBM, Oracle, Andersen Consulting) имеют свои собственные методики и руководства по управлению проектами.

Что же должен содержать стандарт предприятия по управлению проектами? Он должен быть основан на так называемых рамочных стандартах, которые содержат самые общие принципы проектного менеджмента. Это такие документы, как Project Management Body of Knowledge (PMBOK) Американского института управления проектами (PMI), стандарт ISO 10006:1997, российский НТК (Национальные требования к компетентности). Каждое предприятие в какой-то мере уникально, поэтому рамочные стандарты должны быть адаптированы под конкретные условия управления проектами. Этого можно достичь, применяя подходы специализации и детализации стандартов.

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

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

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

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

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

Объем стандарта предприятия по управлению проектами зависит от степени детализации стандарта и перечня основных документов. Их можно представить в виде пирамиды, растущей сверху вниз – Политика руководства по управлению проектами – Процедуры управления проектом – Детальные инструкции по исполнению процедур – Шаблоны документов (рисунок «Структура стандарта управления проектами»).

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

Понятие, состав и виды проектов. Этапы управления проектами на предприятии. Организационно-экономическая характеристика ТОО "Казцинктех". Анализ экономических показателей работы предприятия. Основные проблемы в управления проектами и пути их решения.

дипломная работа , добавлен 22.05.2012


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

дипломная работа , добавлен 23.08.2011


Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.

дипломная работа , добавлен 20.08.2017


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

курсовая работа , добавлен 23.11.2010


Характеристика этапов развития управления проектами в России. Понятие, роль и актуальность проектного управления. Основные формы планирования и контроля текущей деятельности фирмы. Особенности управления проектами в фирмах-партнерах "1С:Франчайзи".

курсовая работа , добавлен 23.10.2015


Сущность управления инновационными проектами. Классификация инновационных проектов, идеи, замыслы и технические решения. Фазы жизненного цикла проекта и основные области его приложения. Программное обеспечение управления инновационными проектами.

реферат , добавлен 29.09.2012


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

курсовая работа , добавлен 05.11.2011

Министерство образования и науки Республики Казахстан

Восточно-Казахстанский государственный университет

им. С. Аманжолова

«Допущена к защите»

«____»____________2012г.

Заведующийкафедрой «Менеджмент и маркетинг»

______________ Г.К. Койшинова

ДИПЛОМНАЯ РАБОТА

На тему: «Совершенствование процесса управления проектами на предприятии ТОО «Казцинктех»

по специальности 050700 - «Менеджмент»

Выполнил студент

группы МН08

А.П. Поваренкина

Научный руководитель

Преподаватель А.К. Рахметова

Нормоконтролер

А.К. Рахметова

Усть-Каменогорск 2012

Введение

1. Теоретические аспекты управления проектами

1 Понятие, состав и виды проектов

2 Управление проектами на предприятии (этапы управления)

2. Управление проектами ТОО «Казцинктех»

1 Организационно-экономическая характеристика ТОО «Казцинктех»

2 Система проектирования ТОО «Казцинктех»

3 Анализ основных экономических показателей работы предприятия

3. Совершенствование процесса управления проектами в ТОО «Казцинктех»

3.1 Основные проблемы в управления проектами и пути их решения

Заключение

Список литературы

Введение

Закон Лермана гласит: «Любую техническую проблему можно преодолеть, имея достаточно времени и денег», а следствие Лермана уточняет: «Вам никогда не будет хватать либо времени, либо денег». Именно для преодоления сформулированной в следствии Лермана проблемы и была разработана методика управления деятельностью на основе проекта. А распространение данной методики управления на различные сферы деятельности является дополнительным доказательством ее эффективности. Если попросить менеджера описать, как он понимает свою основную задачу в выполнении проекта, то скорее всего он ответит: «Обеспечить выполнение работ». Это действительно главная задача руководителя. Но если задать тот же вопрос более опытному менеджеру, то можно услышать и более полное определение главной задачи менеджера проекта: «Обеспечить выполнение работ в срок, в рамках выделенных средств, в соответствии с техническим заданием». Именно эти три момента: время, бюджет и качество работ находятся под постоянным вниманием руководителя проекта. Их также можно назвать основными ограничениями, накладываемыми на проект. Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, денежным средствам (и ресурсам), а также качеству конечных результатов проекта (документированных, например, в техническом задании).

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

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

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

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

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

Ознакомление с предприятием. Здесь отражаются такие особенности, как:

-организационно-правовая форма;

-вид хозяйственной деятельности;

-номенклатура производимой продукции, услуг;

-основные поставщики сырья и материалов и потребители продукции, услуг;

-основные конкуренты;

-объем производства;

-структура предприятия, его цехов и подразделений;

-численность профессиональных групп рабочих и специалистов;

-технико-экономические показатели работы предприятия.

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

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

В итоге определяется стратегия развития (сокращения) предприятия и проводится ее оценка путем сравнения результатов с целями.

Работа в отделе маркетинга (снабжения и сбыта). Следует кратко описать основные направления деятельности данной службы, привести ряд примеров организаторской работы руководителя, дать предложения по совершенствованию управления.

Работа в отделе труда и заработной платы. Необходимо изучить разделение труда, организацию труда основного рабочего (рабочие приемы, методы обслуживания, планирование работы), нормирование труда основного рабочего, систему стимулирования труда.

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

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

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

1. Теоретические аспекты управления проектами

.1 Понятие, состав и виды проектов

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

Что же такое проект? Все мы постоянно осуществляем проекты в своей повседневной жизни. Вот простые примеры: подготовка к юбилею, ремонт в квартире, проведение исследований, написание книги... Все эти виды деятельности имеют между собой целый ряд общих признаков, делающих их проектами:

они направлены на достижение конкретных целей;

они включают в себя координированное выполнение взаимосвязанных действий;

они имеют ограниченную протяженность во времени, с определенным началом и концом;

все они в определенной степени неповторимы и уникальны.

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

Управление проектом (проектное управление) - вид управленческой деятельности, базирующийся на предварительной тщательной разработке модели действий по достижению конкретной цели.

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

Современное управление проектом - это особый вид управления, который может применяться к управлению любыми объектами.

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

Цель содержит в себе основную идею проекта и определяет проект и деятельность по его реализации в целом. В проектном управлении цель декомпозируется на осознаваемые и управляемые элементы деятельности, логически и организационно связанные в комплексы и пакеты работ.

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

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

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

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

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

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

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

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

Наиболее активными непосредственными участниками проекта выступают:

инициатор проекта;

заказчик;

инвестор;

руководитель проекта;

команда проекта.

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

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

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

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

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

К участникам проекта относятся:

-контрактор;

-субконтрактор;

-потребитель продукции проекта.

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

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

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

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

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

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

1) разработка проекта (полной модели); 2) его реализация (воплощение модели в предметной области).

На фазе разработки происходит осознание и формирование целей проекта, создание полной и частных моделей, подготовка решений и планов, их анализ и утверждение проектной документации (бизнес-проекта).

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

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

Обе фазы характеризуются следующими особенностями:

-затраты на фазе разработки существенно ниже, чем на фазе реализации; уровень затрат и совокупных усилий в динамике напоминает асимметричную, смещенную вправо кривую плотности распределения случайной величины;

-количество участников проекта на фазе разработки обычно значительно меньше, чем на фазе реализации;

-вероятность неудачи проекта на фазе разработки высока, но по мере завершения риски проекта снижаются;

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

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

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

-схеме взаимоотношений участников проекта;

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

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

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

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

Организационное проектирование заканчивается созданием пакета организационной, методической и справочной документации» включающего:

-организационную структуру управления проектом (графическое изображение структурных единиц);

-штатное расписание (перечень должностей, их количества и заработной платы);

-положения о структурных подразделениях;

-должностные инструкции;

-методические инструкции, технологические карты процессов и пр.;

-требования к персоналу (профессиограммы, социально-психологические портреты).

Таблица 1 Сравнение организационных структур управления проектом

Характеристики проектаОрганизационная структура управленияфункциональнаяматричнаяпроектно-целеваяслабаясбалансированнаясильнаяПолномочия руководителя проектаКрайне незначительныеОграниченныеОт слабых до среднихОт средних До высокихОт высоких до неограниченныхДоля организационных ресурсов, задействованных для выполнения проекта, %0От 0 до 25От 15 до 60От 50 до 95От 85 до 100Роль руководителя проектаВременнаяВременнаяПостояннаяПостояннаяПостояннаяНазвания руководителя проектаКоординатор/ лидер проектаКоординатор/лидер проектаПроект-менеджер/ руководитель проектаПроект-менеджер/ руководитель программыПроект-менеджер/ руководитель программыСтатус команды проектаВременныйВременныйВременныйПостоянныйПостоянный

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

1.2 Управление проектами на предприятии (этапы управления)

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

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

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

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

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

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

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

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

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

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

Ограничение по срокам. Означает, что у любого проекта есть четкое начало и четкое завершение. Проект - временное явление в жизни компании: он как бы «вклинивается» в ее повседневную работу. Для проекта определяют цели, под него выделяют ресурсы. Потом проект реализуется и завершается, а люди возвращаются к своей повседневной работе. Значительная часть усилий при работе с проектом направлена именно на обеспечение того, чтобы проект был завершен в намеченное время. Завершение наступает, когда достигнуты цели проекта; или осознано, что цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте, и он прекращается. Проект живет от момента времени «еще нет» и до момента «пока нет».

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

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

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

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

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

Предпосылки перехода к проектному управлению.

В качестве самостоятельной области знаний управление проектами начало формироваться в начале ХХ века. Наиболее известные центры компетенции:

PMI, Project Management Institute, PMBOK - американский национальный стандарт ANSI/PMI 99-001-2004.

IPMA, International Project Management Association. В России - СОВНЕТ.

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

Эпоха перемен. Все в мире стало непрерывно и стремительно изменяться. Изобилие стало причиной острейшей конкуренции. Инновации - неотъемлемый атрибут нашего времени. «Если у вас медленный доступ в Интернет, вы можете навсегда отстать от развития информационных технологий». Практика должна постоянно перестраиваться применительно к новым и новым условиям. Пример. Hewlett-Packard получает большую долю прибыли на товарах, которые год назад даже не существовали

Глобализация. Всеобщая взаимозависимость и взаимосвязанность. Транснациональные компании. Бизнес идет туда, где дешевле рабочая сила. Интернет. Конкуренция без границ. Пример. Google. За ночь любой из нас в принципе может создать многомиллионную компанию у себя в гараже. С помощью Интернета вы можете выйти на рынок, на котором более 100 млн. потребителей.

Все решают таланты. Простая мобилизация средств и усилий уже не может обеспечить прогресс. Вспомним Ф. Брукса, «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Идею богатства теперь связывают не с деньгами, а с людьми, не с финансовым капиталом, а с «человеческим». Рынок труда превращается в рынок независимых специалистов и его участникам все больше известно о возможных вариантах выбора . Работники интеллектуального труда начинают самостоятельно определять себе цену. Человечеству известны два вида деятельности. Репродуктивная деятельность (труд) является слепком, копией с деятельности другого человека либо копией своей собственной деятельности, освоенной в предшествующем опыте. Такая деятельность, как, например, труд токаря в любом механическом цеху, или рутинная повседневная деятельность менеджера-управленца на уровне раз и навсегда усвоенных технологий. Продуктивная деятельность (творчество) - деятельность, направленная на получение объективно нового или субъективно нового (для данного работника) результата. Репродуктивная деятельность уходит в прошлое. В постиндустриальном обществе интеллект - основная производственная сила. Сегодня от 70 до 80% всего, что сегодня делается людьми, производится при помощи их интеллекта. В любом товаре, сделанном в США, доля зарплаты составляет 70 процентов. Но это в среднем по всем товарам.

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

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

Определение управления проектами.

Управление проектами - это приложение знаний, опыта, методов и средств к работам проекта для удовлетворения требований, предъявляемых к проекту, и ожиданий участников проекта.

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

Если попросить менеджера описать, как он понимает свою основную задачу в выполнении проекта, то скорее всего он ответит: «Обеспечить выполнение работ».

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

Именно эти три момента:

качество работ;

находятся под постоянным вниманием руководителя проекта.

Их также можно назвать основными ограничениями, накладываемыми на проект.

Управление проектами заключается в составлении плана работ и отслеживании их выполнения.

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

Управление проектами также пытается минимизировать риски, с которыми вы сталкиваетесь.

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

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

Планирование.

Бюджетирование.

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

Контроль выполнения.

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

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

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

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

Считается, что эффективное управление сроками работ является ключом к успеху по всем трем показателям.

Временные ограничения проекта часто являются наиболее критичными.

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

Поэтому, в большинстве методов управления проектами основной акцент делается на календарном планировании работ и контроле за соблюдением календарного графика. определяет «управление проектами» следующим образом:

Управление проектом (УП) или Project Management (PM) - это искусство руководства и координации людских и материальных ресурсов на протяжении жизненного цикла проекта путем применения современных методов и техники управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта.

Критерии успешности проекта.

Задача проекта - достижение конкретной бизнес-цели, при соблюдении ограничений «проектный треугольника» в соответствии с рисунком 2. Это означает, что ни один из углов треугольника не может быть изменен без оказания влияния на другие. Например, чтобы уменьшить время, потребуется увеличить стоимость и/или сократить содержание.

Как мы уже знаем, большинство проектов имеют определенную дату окончания, бюджет и объем работ.

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

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

Например, если вы решите изменить план проекта, укоротив расписание, то возрастет стоимость проекта (если вы решите привлечь дополнительных работников) или уменьшится объем работ.

Если же изменить план проекта с целью уменьшения его бюджета, то может возрасти длительность проекта и уменьшиться объем работ.

Наконец, если вы увеличите объем работ, то проект будет длиться дольше и стоить дороже.

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

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

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

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

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

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

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

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

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

Эффективность это отношение полученного результата к произведенным затратам. Нельзя рассматривать эффективность, исходя только из результативности: чем больше ты производишь, чем больше делаешь, тем выше твоя эффективность. С таким подходом можно «зарезать на ужин курицу, несущую золотые яйца». Затраты не следует путать с инвестициями. Оплата аренды, электроэнергии, коммунальные платежи - затраты. Создание и закрепление эффективной команды - это стратегическое приобретение компании. Обучение участников проекта - инвестиции. Вложение в людей - это увеличение числителя в формуле эффективности. Уход из компании всех профессионалов после проекта, выполненного по принципу «любой ценой», - затраты, причем очень тяжело восполняемые. Нарастающая конкуренция указывает на совершенно четкий тренд в мировой экономике - персонал - это форма инвестиций, активов, которые нужно уметь наращивать, управлять и сохранять. Сегодня люди - это капитал. Современное предприятие обязано относиться к своим работникам так же, как к своим лучшим клиентам. Главный капитал современной компании - это знания.

Большая часть этих знаний неотъемлема от их носителя - человека. Те предприятия, которые этого не поняли, не выживут потому, что не смогут быть эффективными. Сегодня эффективное предприятие - это сервис. Предприятие, с одной стороны, предоставляет услуги и продукты своим клиентам, а с другой, - рабочие места для профессионального персонала. Принципы «Одно предприятие на всю жизнь», «Работай продуктивно, а предприятие о тебе позаботится» - уходят в прошлое. Посмотрите на рынок рабочей силы в ИТ - правила устанавливают профессионалы.

Классификация проектов.

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

Классификация проектов может быть проведена по различным основаниям. Мы рассмотрим лишь наиболее распространенные ее варианты в соответствии с рисунком 3

Классификация по сферам деятельности

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

Организационный (реформирование существующего или создание нового предприятия, внедрение новой системы управления, проведение международной конференции и т.д.).

Экономический (приватизация предприятия, внедрение системы финансового планирования и бюджетирования, введение новой системы налогообложения и т.д.).

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

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

Классификация проектов по размерности.

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

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

Мегапроект - целевые программы развития регионов, отраслей и др. образований, включающие в свой состав ряд моно- и мультипроектов («План Маршалла», создание Общеевропейского рынка, развитие Южной Кореи и т.д.).

Классификация по объемам финансирования проекта

По объемам финансирования проекты можно разделить на малые, средние и крупные.

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

Так, в американской практике существуют прецеденты, когда к малым проектам относят проекты с объемом капиталовложений до $10-15 млн.и трудозатратами до 40-50 тыс. человеко-часов. (Примеры: опытно-промышленные установки, небольшие промышленные предприятия, модернизация действующих производств).

В казахстанской практике к малым проектам можно отнести проекты с объемом финансирования до $200- 300 тыс. А проекты с объемом финансирования свыше $10-15 млн. уже относят, как правило, к крупным.

Классификация по целевому назначению проекта

Инвестиционный - главная цель - создание или обновление основных фондов организаций, требующие вложения инвестиций.

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

Научно-исследовательский.Учебно-образовательный. Смешанный.Организационные аспекты управления проектами.Определенные фирмы работают исключительно по принципу проектных работ - строительные компании.

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

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

Рисунок 4 Схема значимости властных полномочий руководителя проекта

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

Функциональная структура имеет следующие особенности:

Сохраняется принцип единоначалия.

Понятные и стабильные условия работы.

Хорошо приспособлены для операционной деятельности.

Специализация подразделений позволяет накапливать экспертизу.

Затруднено принятие решений и коммуникации между исполнителями. Осуществляются только через руководство.

Управление сконцентрировано и держится на компетенции высшего руководства. Как правило, неэффективен контроль за ходом проекта (нет целостной картины)

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

В чисто проектных организациях:

Проект организуется как самостоятельное производственное подразделение.

Персонал на проект набирается по временным контрактам.

После завершения проекта персонал увольняется.

Медленный старт.

Опыт не аккумулируется.

Команды не сохраняются.

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

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

В слабой матрице роль и полномочия сотрудника, который координирует проект, сильно ограничены. Реальное руководство проектом осуществляет один из функциональных руководителей. Координатор проекта, его еще часто называют «трекер», помогает этому руководителю собирать информацию о статусе выполняемых проектных работ, учитывает затраты, составляет отчеты.

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

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

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

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

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

По поводу технологий ЕРМ - это совокупный результат реализации этих стратегий - среда, "созидающая стоимость": управление эффективностью предприятия (Enterprise Performance Management, EPM). EPM - это и стратегия, и процесс соединения традиционных бизнес измерений с нематериальными активами, как, например, потенциалом творческих работников, поведением клиента; совместными знаниями, присутствующими во всей организации; жизнеспособностью отношений с поставщиками.

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

Организация проектной команды

Выше сказано о способах формирования проектных структур, задачах офиса управления проектами. Как формируется проектная команда? Кто ее формирует?

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

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

Высшее руководство компании (оно может называться по-разному: генеральный директор, совет директоров, правление и т.д.) - утверждает {цели} проекта, принимает у {менеджера} его результаты.

Куратор («спонсор») проекта - представитель высшего руководства, который, с одной стороны, контролирует проект, а с другой - помогает менеджеру лоббировать его на высшем уровне.

Если проект большой, то кроме менеджера проекта, в команду управления проектом входят другие руководители, например, главный инженер проекта (ГИП).

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

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

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

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

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

Лидерство и управление. В работе руководителя проекта есть две стороны: управление и лидерство, которые одинаково важны и не могут существовать в отрыве друг от друга. Нельзя быть лидером материальных ресурсов, денежных потоков, планов, графиков и рисков. Ими необходимо управлять. Потому что у вещей нет права и свободы выбора, присущих только человеку.

Интеллектуальными людьми невозможно управлять. Творческие команды можно только направлять и вести. «Высокопроизводительное управление в отсутствие эффективного лидерства подобно упорядочению расстановки стульев на палубе тонущего «Титаника». Никакой успех в управлении не компенсирует провала в лидерстве».

Эффективные команды не образуются сами по себе, они кристаллизуются вокруг признанного лидера. Как не бывает лидеров без последователей, так и не бывает команд без лидеров. Поэтому первый шаг руководителя при создании эффективной команды - это стать лидером, вокруг которого сможет сплотиться рабочий коллектив. Лидера нельзя назначить.

Лидерство, это в первую очередь, это умение управлять своей собственной жизнью и только потом другими людьми. Сверхвысокое значение коэффициента интеллекта IQ, к сожалению, в этом не поможет. Личная эффективность человека на 80% определяется его коэффициентом эмоционального интеллекта EQ (Emotional Intelligence) - способностью понимать и эффективно взаимодействовать с другими людьми. Хорошая новость. В отличие от IQ, который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни. Если, конечно, прилагать к этому усилия.

Если руководитель не смог стать лидером, он будет вынужден применять в своей практике управленческие антипаттерны. Для такого руководителя характерны чрезмерная настороженность, скрытность, неспособность делегировать полномочия. Он исходит из предпосылок индустриальной эпохи Генри Форда: «Работники ленивы, поэтому им необходимы внешние стимулы для работы. У людей нет честолюбия, и они стараются избавиться от ответственности. Чтобы заставить людей трудиться, необходимо использовать принуждение, контроль и угрозу наказания».

Жизненный цикл проекта.

На практике количество фаз проекта, как правило, варьируется от 4 до 9 (но может быть и больше).

Каждая фаза может характеризоваться по таким параметрам, как:

стоимость;

продолжительность;

степень вовлечения персонала;

степень вероятности успеха проекта;

влияние ключевых участников.

Все эти характеристики зависят от конкретного проекта, условий его реализации и опыта участников.

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

Основные фазы жизненного цикла проекта

Типичный жизненный цикл проекта, как видно в соответствии с рисунком 11, состоит из четырех фаз:

Начальная фаза (концепция).

Фаза разработки.

Фаза реализации.

Фаза завершения.

Рисунок 5 Жизненный цикл проекта

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

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

Достаточно часто возможно параллельное выполнение работ разных фаз, что вызывает перекрытие фаз и сокращение продолжительности проекта в целом.

Какие работы входят в состав основных фаз проекта?

Фаза концепции посвящена разработке концепции проекта и включает в себя:

Сбор исходных данных и анализ существующего состояния (предварительное обследование).

Выявление потребности в изменениях (в проекте).

Определение проекта:

цели, задачи, результаты;

основные требования, ограничительные условия, критерии;

уровень риска;

окружение проекта, потенциальные участники;

требуемое время, ресурсы, средства и др.

Определение и сравнительная оценка альтернатив.

Представление предложений, их апробация и экспертиза.

Утверждение концепции и получение одобрения для следующей фазы.

В фазе разработки разрабатываются основные компоненты проекта, и осуществляется подготовка к его реализации.

Основные работы этой фазы:

) Назначение руководителя проекта и формирование команды проекта, в первую очередь ключевых членов команды.

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

) Развитие концепции и разработка основного содержания проекта:

конечный результат(ы) и продукт(ы), стандарты качества, структура проекта, основные работы, требуемые ресурсы.

) Структурное планирование:

декомпозиция проекта;

календарные планы и укрупненные графики работ и обеспечения;

смета и бюджет проекта;

потребность в ресурсах;

процедуры УП и техника контроля;

определение и распределение рисков.

) Организация и проведение торгов, заключение субконтрактов с основными исполнителями.

) Организация выполнения базовых проектных и опытно-конструкторских работ по проекту.

) Представление проектной разработки.

) Получение одобрения на продолжение работ по проекту.

В фазе реализации выполняются основные работы, необходимые для достижения проекта.

Данная фаза включает в себя:

) Организацию и проведение торгов, заключение контрактов.

) Полный ввод в действие разработанной системы УП.

) Организацию выполнения работ.

) Ввод в действие средств и способов коммуникации и связи участников проекта.

) Ввод в действие системы стимулирования (участников) проекта.

) Детальное проектирование и технические спецификации.

) Оперативное планирование работ.

) Установление системы информационного контроля за ходом работ.

) Организацию и управление материально-техническим обеспечением работ, в т.ч. запасами, закупками.

) Выполнение работ, предусмотренных проектом (в т.ч. производство строительно - монтажных и пуско-наладочных работ).

) Руководство, координация работ, согласование темпов, мониторинг прогресса, прогноз состояния, оперативный контроль и регулирование основных показателей проекта:

ход работ, их темпы;

качество работ и проекта;

продолжительность и сроки;

стоимость и другие показатели.

) Решение возникающих проблем и задач.

В завершающей фазе (или фазе окончания) проекта достигаются конечные цели проекта, подводятся итоги, разрешаются конфликты и проводится закрытие проекта.

Основные работы этой фазы:

1)планирование процесса завершения;

2)эксплутационные испытания окончательного продукта(ов) проекта;

)подготовка кадров для эксплуатации создаваемого объекта;

)подготовка документации, сдача объекта заказчику и ввод в эксплуатацию;

)оценка результатов проекта и подведение итогов;

)подготовка итоговых документов;

)закрытие работ и проекта;

)реализация оставшихся ресурсов;

)накопление фактических и опытных данных для последующих проектов;

)расформирование команды проекта.

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

Функциональные области управление проектом

Управления проектом можно разделить на более или менее самостоятельные блоки - области знаний по управление проектом

Управление интеграцией проекта (Project Integration Management) - описывает мероприятия, необходимые для того, чтобы различные составляющие проекта координировались должным образом.

Разработка сводного плана проекта. Выполнение сводного плана проекта. Общее управление изменениями.

Управление содержанием проекта (Project Scope Management) - описывает действия, необходимые для четкого определения, что именно должно быть сделано в ходе выполнения проекта, а что выходит за его рамки.

Инициализация. Планирование содержания проекта. Определение содержания проекта. Подтверждение содержания проекта. Контроль изменений содержания проекта.

Управление временными параметрами проекта (Project Time Management) - описывает действия, необходимые для завершения проекта в срок. Определение состава работ. Определение последовательности работ. Оценка продолжительности работ. Разработка графика проекта. Контроль хода выполнения.

Управление стоимостью проекта (Project Cost Management)- описывает действия, гарантирующие, что проект будет выполнен в рамках утвержденного бюджета. Планирование ресурсов. Оценка затрат. Составление бюджета проекта. Контроль исполнения бюджета.

Управление качеством в проекте (Project Quality Management)- описывает действия, необходимые для гарантии того, что результат проекта будет удовлетворять требованиям, ради которых он был предпринят. Планирование качества. Обеспечение качества. Контроль качества.

Управление человеческими ресурсами (Project Human Resource Management) - описывает действия, обеспечивающие оптимальное использование человеческих и прочих ресурсов, вовлеченных в проект. Планирование организации проекта. Набор персонала. Формирование команды проекта.

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

Управление рисками проекта (Project Risk Management) - описывает действия по идентификации и анализу проектных рисков, а также методы реагирования на них. Идентификация рисков. Количественная оценка рисков. Разработка методов реагирования. Контроль реагирования.

Управление поставками(Project Procurement Management). - описывает действия по управлению процессом получения необходимых для проекта товаров и услуг со стороны внешних по отношению к проекту организаций и лиц. Планирование поставок. Планирование работы с поставщиками. Сбор коммерческих предложений. Выбор поставщиков. Управление контрактами. Закрытие контрактов.

Процессы управления проектами

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

Проект состоит из процессов.

Процесс - это совокупность действий, приносящая результат.

Процессы проекта обычно выполняются людьми и распадаются на две основные группы:

1. процессы управления проектами - касающиеся организации и описания работ проекта (которые будут подробно описаны далее);

2. процессы, ориентированные на продукт - касающиеся спецификации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложения.

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

Процессы управления проектами могут быть разбиты на шесть основных групп, реализующих различные функции управления:

Процессы инициации (Initiating Processes) - принятие решения о начале выполнения проекта;

Процессы планирования (Planning Processes) - определение целей и критериев успеха проекта и разработка рабочих схем их достижения;

Процессы исполнения (Executing Processes) - координация людей и других ресурсов для выполнения плана;

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

Процессы управления (Controlling Processes) - определение необходимых корректирующих воздействий, их согласование, утверждение и применение;

Процессы завершения(Closing Processes) - формализация выполнения проекта и подведение его к упорядоченному финалу.

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

Рисунок 6 Наложение процессов

Кроме того, процессы управления проектами связаны своими результатами - результат выполнения одного становится исходной информацией для другого.

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

Процессы инициации. Инициация включает единственный подпроцесс - авторизацию, то есть решение начать проект или следующую фазу проекта.

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

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

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

Концепция (от лат. conceptio - понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения.

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

Приоритет любого проекта должен определяться на основе оценки трех его характеристик:

) Финансовая ценность.

) Стратегическая ценность.

) Уровень рисков.

Шкала оценки финансовой ценности проекта может выглядеть следующим образом:

Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованны.

Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания.

Средняя. Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.

Низкая. Проект немного снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства.

Шкала оценки стратегической ценности проекта может иметь следующий вид:

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

Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года.

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

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

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

Примерная шкала оценки уровня рисков проекта может иметь следующий вид:

Низкий. Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы.

Средний. Цели проекта определены более-менее четко. Хорошее понимание требований к системе. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются на новой, но стабильной технологической платформе.

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

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

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

Концепция проекта.

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

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

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

) Название проекта.

) Цели проекта.

) Результаты проекта

) Допущения и ограничения.

) Ключевые участники и заинтересованные стороны.

) Ресурсы проекта.

) Критерии приемки.

) Обоснование полезности проекта.

Основные процессы планирования

Некоторые из процессов планирования имеют четкие логические и информационные взаимосвязи и выполняются в одном порядке практически во всех проектах.

К основным процессам планирования относятся:

Планирование целей - разработка постановки задачи (проектное обоснование, основные этапы и цели проекта),

Декомпозиция целей - декомпозиция этапов проекта на более мелкие и более управляемые компоненты для обеспечения более действенного контроля,

Определение состава операций (работ) проекта - составление перечня операций, из которых состоит выполнение различных этапов проекта,

Определение взаимосвязей операций - составление и документирование технологических взаимосвязей между операциями,

Оценка длительностей или объемов работ - оценка количества рабочих временных интервалов, либо объемов работ, необходимых для завершения отдельных операций,

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

Назначение ресурсов - определение ресурсов, необходимых для выполнения отдельных операций проекта;

Оценка стоимостей - определение составляющих стоимостей операций проекта и оценка этих составляющих для каждой операции, ресурса и назначения;

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

Оценка бюджета - приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам);

Разработка плана исполнения проекта - интеграция результатов остальных подпроцессов для составления полного документа.

Определение критериев успеха - разработка критериев оценки исполнения проекта.

Вспомогательные процессы планирования

Кроме перечисленных основных процессов планирования имеется ряд вспомогательных процессов, необходимость в использовании которых сильно зависит от природы конкретного проекта.

Такие процессы включают в себя:

Планирование качества - определение того, какие стандарты качества использовать в проекте, и того, как эти стандарты достичь;

Планирование организации - определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации;

Назначение персонала - назначение человеческих ресурсов на выполнение работ проекта;

Планирование взаимодействия - определение потоков информации и способов взаимодействия, необходимых для участников проекта,

Идентификация риска - определение и документирование событий риска, которые могут повлиять на проект;

Оценка риска - оценка вероятностей наступления событий риска, их характеристик и влияния на проект;

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

Планирование поставок - определение того, что, как и когда должно быть поставлено;

Подготовка условий - выработка требований к поставкам и определение потенциальных поставщиков.

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

Описание этапа планирования проекта

Этап планирования является одним из самых важных.

На этом этапе определяются задачи, бюджет и сроки проекта.

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

Полноценная техника планирования включает в себя следующие этапы и последовательность:

) Определение цели проекта и ее описание. Довольно часто проекты начинаются без четких и измеримых целей.

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

В какие сроки должна быть достигнута цель?

Какие условия достижения цели есть в наличии (бюджет, ресурсы, технология)?

Каким способом измерить достижение цели?

Как распределены обязанности в проекте (кто за что отвечает)?

Согласен ли инвестор (заказчик) с определением цели и условиями ее достижения?

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

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

) Необходимо согласовать вопрос о выделяемых ресурсах для проекта.

Следует отметить, что все ресурсы компании должны распределяться централизованно.

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

Для решения данной проблемы на все проекты в компании должны быть расставлены приоритеты.

) График работ в таких системах, как Microsoft Project, получается автоматически, если определены задачи и ресурсы.

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

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

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

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

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

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

Процессы исполнения и контроля.

Исполнение - реализация составленного плана.

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

Как и в планировании, процессы исполнения можно подразделить на основные и вспомогательные.

К основным процессам можно отнести сам процесс исполнения плана проекта.

Среди вспомогательных процессов можно отметить:

учет исполнения - подготовка и распределение необходимой для участников проекта информации с требуемой периодичностью;

подтверждение качества - регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам качества;

выбор поставщиков - оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов;

контроль контрактов - контроль исполнения контрактов поставщиками и подрядчиками;

развитие команды проекта - повышение квалификации участников команды проекта.

Процессы анализа. Процессы анализа включают как анализ плана, так и анализ исполнения проекта.

Анализ плана - это определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта.

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

В дальнейшем под процессами анализа понимаются процессы анализа исполнения.

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

Процессы анализа также можно подразделить на основные и вспомогательные.

К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта:

анализ сроков - определение соответствия фактических и прогнозных сроков исполнения операций проекта директивным или запланированным;

анализ стоимости - определение соответствия фактической и прогнозной стоимости операций и фаз проекта директивным или запланированным;

анализ качества - мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определения путей устранения причин нежелательных результатов исполнения качества проекта;

подтверждение целей - процесс формальной приемки результатов проекта его участниками (инвесторами, потребителями и т. д.).

Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:

оценку исполнения - анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта;

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

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

Процессы управления. Управление исполнением проекта - это определение и применение необходимых управляющих воздействий с целью успешной реализации проекта.

Если исполнение проекта происходит в соответствии с намеченным планом, то управление фактически сводится к исполнению - доведению до участников проекта плановых заданий и контролю их реализации. Эти процессы включены в процессы исполнения.

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

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

Такие процессы управления часто называются управлением изменениями.

К основным процессам управления, встречающимся практически в каждом проекте, относятся:

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

управление ресурсами - внесение изменений в состав и назначения ресурсов на работы проекта;

управление целями - корректировка целей проекта по результатам процессов анализа;

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

Среди вспомогательных процессов управления можно отметить:

управление рисками - реагирование на события и изменение рисков в процессе исполнения проекта;

управление контрактами - координация работы (суб)подрядчиков, корректировка контрактов, разрешение конфликтов.

Процессы завершения. Завершение проекта сопровождается следующими процессами:

закрытие контрактов - завершение и закрытие контрактов, включая разрешение всех возникших споров;

административное завершение - подготовка, сбор и распределение информации, необходимой для формального завершения проекта.

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

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

Методы управления проектами. В 50-х годах было разработано два схожих метода управления работами по реализации проектов.

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

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

Метод критического пути. Критический путь в проекте - это самая длительная (по срокам) последовательная цепочка, операций.

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

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

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

Сетевой график работ. Третий этап включает анализ отношений очередности операций и составление сетевого графика, отражающего эти отношения.

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

Календарный сетевой график. Четвертый этап предусматривает построение календарного сетевого графика на основе оценок продолжительности операций и полученной сетки.

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

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

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

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

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

Важнейшие виды ресурсов: время, финансовые средства, трудовые ресурсы.

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

) описание работ проекта;

) описание взаимосвязи работ;

) назначения ресурсов по работам проекта;

) календарное расписание всего проекта в целом.

2. Управление проектами ТОО «Казцинктех»

.1 Организационно-экономическая характеристика ТОО «Казцинктек»

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

Цели и задачи деятельности «Казцинктех».

Обеспечение текущей деятельности, инвестиционных проектов компании ТОО «Казцинктех» по:

1.Научно-техническими исследованиями.

2.Проектной продукцией всех видов и типов, для всех сфер деятельности компании:

Поддержанию основных фондов производства в рабочем состоянии (ремонты), восполнению выбывающих мощностей горной добычи.

Реконструкции действующих производств.

Развитию мощностей новых производств (новое строительство).

С учетом собственных возможностей и корпоративных требований компании, по качеству, срокам, стоимости.

ТОО «Казцинктех» разрабатывает проектную продукцию, по направлениям:

.Горное производство- вскрытие и отработка месторождений полезных ископаемых.

2.Обогатительное производство- обогащение полезных ископаемых, до товарных концентратов.

.Металлургическое производство - металлургическая переработка концентратов цветных металлов.

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

.Машиностроительное производство.

.Энергетическое производство.

.Объекты социально - бытового назначения.

2.2 Система проектирования ТОО «Казцинктех»

Таблица 2 Оценка слабых и сильных сторон деятельности «Казцинктех»

Сильные стороныСлабые стороны1Непосредственная близость отделений «Казцинктех» к ключевым подразделениям. Знание существующего положения производств материнской компании, дочерних компаний1Внешние факторы Отсутствие административной самостоятельности в нормировании ПИР, собственном развитии.2Квалификация кадров, опыт проектирования2Внутренние факторы Недостаточные возможности комплексного проектирования3Гибкость и оперативность решения задач материнской компании, по приоритетам3Низкое качество проработки технологических решений4Техническая оснащённость процессов проектирования4Отсутствие практики выполнения квалифицированных ТЭО5Контролируемая стоимость проектирования5Отсутствие системы планомерного развития методико-нормативной базы проектирования6Широкий спектр тематики работ6Отсутствие системы повышения квалификации персонала (обучение)7Полное отсутствие системы авторского надзора за проектами8Не достаточный уровень системы управления проектами ГИПами9Низкий уровень подготовки исходных данных для проектирования10Не высокий уровень мотивации персонала11Языковые барьеры (незнание английского языка)12Незнание международных стандартов13Несовершенство системы нормирования, планирования ПИР14Отсутствие технологической последовательности в проектировании, работа с «колес»15Неудовлетворенность клиента, качеством и сроками проектирования16Полное отсутствие системы контроля качества проектной продукции

Удовлетворенность потребителя.

За период с апреля 2009 года по март 2010 года было выпущено проектов стоимостью 106 913 тыс.тенге, из них:

-19104 тыс. тенге по обогатительному производству (19%);

-21 460 тыс. тенге по горному производству (20%);

-64 389 тыс. тенге по металлургии (60%);

-1460 тыс. тенге по прочим отраслям (1%).

Основным Заказчиком проектно-сметной документации является РГОК, но выбранный для отчета период не совсем показательный в этом плане, так как из-за кризиса на РГОКе были приостановлены работы по строительству и соответственно по проектированию.

Но уже по плану на 2010 год доля заказа РГОКа в общем плане РОКП составляет 73% (82 550 тыс. тенге при общем годовом плане ПИР 113 199 тыс. тенге).

В ТОО «Казцинктех» действует Положение "Система оценки проектно-изыскательских работ, выполняемых ТОО "Казцинктех". В соответствии с этим положением за каждый выполненный проект Заказчик выставляет оценку по 5-ти бальной системе, из которых:

3 балла выставляются за соблюдение договорного срока (при неисполнении сроков выставляется ноль баллов);

2 балла выставляются за качество выполненного проекта, два балла выставляются при удовлетворительном качестве проекта (проект принят Заказчиком без замечаний или с незначительными замечаниями), ноль баллов выставляются при неудовлетворительном качестве проекта.

За период с апреля 2009 г. по март 2010 г. была сдана 91 работа, с оценкой 5 сдано 90 работ, что составляет 99%.

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

Средний балл за отчетный год составил 4,98.

Таблица 3 Сведения о стоимости проектах «Казцинктех» за 5 летний период

Общая стоимость проектов, $Капитальное СтроительствоРемонт, РеконструкцияВсего391 291 297108 030 415499 321 712

Производительность труда.

Реализация выполненных проектов за последние годы в стоимостном выражении составила:

в 2008 г - 120 025 тыс. тенге;

в 2009 г - 154 401 тыс. тенге;

в 2011 г - 106 913 тыс. тенге.

Снижение стоимости реализованных проектов в 2010 году по сравнению с 2009 годом объясняется кризисной ситуацией, и как следствие этого, снижением расчетных показателей в 2010 году, а также снижением численности отдела с 63 до 54 человек.

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

Показателем, который в какой-то степени характеризует рост производительности труда, является объем реализованной продукции на одного работающего в ценах, приведенных к 2009 году:

В 2009 году на 1 работающего реализовано 1905,2 тенге/чел, при численности отдела 63 человека;

в 2010 году на 1 работающего реализовано 2301,2 тенге/чел, при численности отдела 63 человека;

в 2011гг на 1 работающего реализовано 2510 тенге/чел, при численности отдела 54 человека.

Порядок, санитарное и эстетическое состояние рабочих мест.

Риддерский отдел комплексного проектирования размещается в арендуемых у РГОКа помещениях, занимает часть здания общей площадью 975 м2.

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

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

Освещение рабочих мест произведено в соответствии с санитарными нормами и правилами.

Каждый рабочий кабинет оснащен кондиционером, профилактика кондиционеров производится ежегодно.

Сведения о профессиональном составе «Казцинктех». Над проектами работают 181 инженеров.

Таблица 4 Основные профильные специальности «Казцинктех»

Наименование специальностейВсего, человекУдельный вес, %2011год УОКПРОКПЗОКПГорные инженеры11647Инженеры технологи32181796Инженеры металлурги8435Инженеры механики137103Инженеры строители37202197Инженеры сантехники19101063Инженеры энергетики23131553Инженеры генплана и транспорта6333Инженеры автоматизации535Инженеры сметчики1810855Инженеры промышленной вентиляции959Итого181100Таблица 5 Сведения о рабочем стаже персонала «Казцинктех»

Наименование специальностейВсего, человекУдельный вес, %2011год УОКПРОКПЗОКПЧисленность персонала всего, в том числе:Чел/%1811014634Со стажем работы, до 5 летЧел/%27/131377Со стажем работы, от 5 -10 летЧел/%27/132151Со стажем работы, от 10 -20 летЧел/%38/2422115Со стажем работы, свыше 20 летЧел/%89/50452321

Таблица 6 Оценка профессиональной деятельности «Казцинктех»

НаименованиеСредний балПерсонал:3,17Возрастной состав3,3Обучение персонала2,0Мотивация3,5Квалификация3,9Материально техническая база3,77Компьютеры, инженерные машины3,5Программное обеспечение3,5Нормативно -техническая база3,8Архивация3,0Программная обеспеченность3,8Обеспеченность рабочих мест (площади)4,0Структура управления3,9Система качества2,0Комплексность проектирования3,8Планирование проектных работ3,9Авторский надзор за реализацией проектов1Исходные данные (в том числе задание на проектирование)3,0Удовлетворенность клиента3,5Всего3,36

Задачи деятельности «Казцинктех»:

1) Исследования (исследовательское отделение), в том числе:

Организация исследований на базе исследовательских лабораторий (закладочных работ, обогащения, металлургии) Маркетинг идей, Регламенты;

оптимизация исследований за счет передчи непрофильных исследований внешним организациям.

2) Мониторинг (отделение мониторинга), в том числе:

1 мониторинг проектирования:

Методология проектирования, внедрения новых форм проектирования, контроль качества проектирования (экспертиза проектов), ценовая политика проектирования

оценка, исследовательских, проектных, строительных, логистических, организационных рисков

) Патентная чистота.

) Архивация, создание и ведение информационной базы, пополнение нормативной базы проектирования

)Организация стажировки, обучения персонала

) Контроль и разработка совершенствование материально - технической базы проектирования (программы, оргтехника)

)Мониторинг за реализацией проектов:

1 разработка предложений по созданию проектных команд по реализации проектов;

) Общий контроль за исполнением бюджетов, сроков, качества, проектов.

) Оказание методической помощи в реализации проектов.

) Организация разработки технической документации по проектам (технологические инструкции, инструкции по профессиям, и т.д.)

) Проектирование (отделение проектирования) (горное, обогатительное, металлургическое производство) , в том числе:

1 Генерация идей, разработка концептуальных идей проектов, маркетинг идей (технологическое бюро).

) Организация, подсчета запасов, технико-экономической оценки запасов (технологическое бюро)

) Выбор технологий, основного технологического оборудования (технологическое бюро совместно с ТП, другими службами).

) Организация, разработки технологических регламентов, с выбором исполнителей (технологическое бюро, совместно с исследовательским бюро)

) Разработки технико-экономических обоснований (технологическое бюро, бюро ТЭО).

) Разработки технических проектов, с выбором субподрядчиков (технологическое бюро, проектные отделы)

) Разработки рабочей документации (технологическое бюро, проектные отделы).

) Локальное проектирование горного производства.

) Строительство (Отделение строительства) , в том числе:

1 организация строительных процессов (строительство, монтаж, шефмонтаж, пусконаладочные работы, запуск), выбор подрядчиков, поставщиков материалов, оборудования, совместно с ТП, службами.

) Ведение ценовой политики строительного производства.

) Контроль качества, сроков, стоимости.

) Контроль состояния ТБ на строящихся объектах.

2.3 Анализ основных экономических показателей работы предприятия

Таблица 7 Основные показатели производственно-хозяйственной деятельности ТОО «Казцинктех» за 2009-2011 гг.

Наименование показателейЕд. изм.2009г.2010 г2011г.Отклонение, +/- 2011 г. от 2010 г.Рост, %2011г. к2010 г.1234567Среднесписочная численностьЧел.2526260100,0Выручка от реализации продукции, всеготыс. тг.376700405000488300+83300120,6Валовой доход, всеготыс. тг.648072008390+1190116,5Услугитыс. тг.210250280+30112,0Издержки обращения, всеготыс. тг.621066507940+1290119,4В том числе: материальные затратытыс. тг. 1340 1080 380 -700 35,2амортизациятыс. тг.4204704700100,0расходы на оплату трудатыс. тг.230023502750+400117,0отчисления на социальные нуждытыс. тг.8208301050+220126,5прочие расходытыс. тг.133019203290+1370171,3Прибыль, всеготыс. тг.250600780+180130,0В том числе: убыток от внереализационных расходовтыс. тг. 6 - - - -от реализации товаровтыс. тг.270520460-6088,5от операционных доходовтыс. тг.4811+3137,5от реализации основных средствтыс. тг.--21+21-Рентабельность продаж, %%0,790,880,95+0,07108,0

Валовой доход ТОО «Казцинктех» за 2011 г. составил за вычетом налога из выручки 8390 тыс. тг.

Существенное влияние на увеличение розничного товарооборота ТОО «Казцинктех» оказали услуги по беспроцентному кредиту сроком на 3 месяца. Так, за 2011 г. оказано услуг в кредит на сумму 3980 тыс. тг.

Издержки обращения за 2011 г. составили 7940 тыс. тг., в том числе:

-амортизация основных средств - 470 тыс. тг. (по сравнению с 2010 г. данный показатель остался без изменений);

-расходы на оплату труда - 2750 тыс. тг. (по сравнению с 2010 г. увеличение составило 400 тыс. тг. или 17,0%);

-отчисления на социальные нужды - 1050 тыс. тг.. (по сравнению с 2010г. увеличение составило 220 тыс. тг. или 26,5%);

-материальные затраты - 380 тыс. тг. (по сравнению с 2010г. уменьшение составило 700 тыс. тг. или 64,8%);

-прочие расходы - 3290 тыс. тг. (по сравнению с 2010 г. увеличение составило 1370 тыс. тг. или 71,3%).

Прибыль ТОО «Казцинктех» за отчетный период составила 780 тыс. тг. (в 2010 г. - 600 тыс. тг.), от операционных доходов - 11 тыс. тг. (в 2010 г. - 8 тыс. тг.), от реализации основных средств - 21 тыс. тг.

Платежеспособность предприятия.

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

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

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

Таблица 8 Анализ активов бухгалтерского баланса ТОО «Казцинктех» за 2009-2011 гг

Наименование статейЕд. изм.2009г.2010г.2011г.Отклонение, +/- 2011 г. от 2010 г.Рост, % 2011 г. к 2010 г.1234567Основные средстваТыс. тг.8900010550074100-3140070,2Нематериальные активыТыс. тг.104030-1075,0Вложения во внеоборотные активыТыс. тг.220430750+320844,2Всего внеоборотных активовТыс. тг.91301102011070+50100,5Запасы и затратыТыс. тг.507059608450+2490141,8В том числе: сырье, материалы и другие активыТыс. тг.320680860+180364,7незавершенное производство и полуфабрикатыТыс. тг.502050+30250,0готовая продукция и товары для реализацииТыс. тг.449052305890+660112,6расходы будущих периодовТыс. тг.2103203200100,0

Наименование статейЕд. изм.2009г.2010г.2011г.Отклонение, +/- 2011 г. от 2010 г.Рост, % 2011 г. к 2010 г.1234567Налоги по приобретенным активамТыс. тг.8801080976-1043,7Дебиторская задолженностьТыс. тг.53010903410+232312,8В том числе: покупателей и заказчиковТыс. тг.120610760+150124,6поставщиков и подрядчиковТыс. тг.230350190-16054,3разных дебиторов и кредиторовТыс. тг.1801302460+23301892,3Денежные средстваТыс. тг.220310360+50116,1Всего оборотных активовТыс. тг.6700844012260+3820145,3Итого (Баланс)Тыс. тг.158301946023330+3870119,9

Проведя анализ активов бухгалтерского баланса за 2009-2011гг. мы видим отклонение основных средств в 2011 году по сравнению с 2010 годом на 31400 тыс. тг., запасы и затраты значительно увеличились в 2010 году на 2490 тыс. тг., также в 2011 году году значительно возросла дебиторская задолженность по сравнению с предыдущими годами.

Таблица 9 Анализ пассива бухгалтерского баланса ТОО «Казцинктех» за 2009-2011 гг

Наименование статейЕд. изм.2008г.2009г.2010г.Отклонение, +/- 2010 г. от 2009 г.Рост, % 2010 г. к 2009 г.1234567Уставный фондТыс. тг.163001630014800-150090,8Собственные акции (доли), выкупленные у акционеров (учредителей)Тыс. тг.--1-10100,0Резервный фондТыс. тг.3030300100,0Добавочный фондТыс. тг.667875960+85109,7Нераспределенная прибыль (непокрытый убыток)Тыс. тг.101020+1200,0Всего капитала и резервовТыс. тг.83401041011120+710106,8Долгосрочные кредиты и займыТыс. тг.5002402210+1970920,8Краткосрочные кредиты и займыТыс. тг.100014002950+1550210,7Кредиторская задолженностьТыс. тг.599074007040-36095,1В том числе: перед поставщиками и подрядчикамиТыс. тг.542063306150-18097,2Наименование статейЕд. изм.2008г.2009г.2010г.Отклонение, +/- 2010 г. от 2009 г.Рост, % 2010 г. к 2009 г.1234567перед покупателями и заказчикамиТыс. тг.230270430+160159,3по оплате трудаТыс. тг.110120160+40133,3по налогам и сборамТыс. тг.70170110-6064,7По социальному страхованию и обеспечениюТыс. тг.303040+10133,3разных кредиторовТыс. тг.130480150-33031,3Резервы предстоящих расходовТыс. тг.-10100100,0Всего обязательствТыс. тг.7490905012210+3160134,9Итого (Баланс)Тыс. тг. 158301946023330+3870119,9

Коэффициент текущей платежеспособности (Ктек. плат.) - это отношение наиболее ликвидных средств к первоочередным долгам:

Ктек. плат. = А1/П1, (1)

где А1 - денежные средства и финансовые вложения);

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

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

Ктек. плат. 2009 = 220/210 » 1,05

Ктек. плат. 2010 = 310/320 » 0,97

Ктек. плат. 2011 = 360/310 » 1,16

Коэффициент абсолютной ликвидности (Кабс. л.) - это отношение легко ликвидных активов ко всем краткосрочным обязательствам предприятия:

Кабс. л. = А1/(П1 + П2 + П3) = А1/КО, (2)

где П2 - задолженность перед поставщиками и подрядчиками, покупателями и заказчиками, которую следует погасить в ближайшее время;

П3 - задолженность банкам по кредитам, сроки погашения которых оговорены в соглашениях и наступят не так скоро;

КО - краткосрочные обязательства.

Этот коэффициент показывает какая часть краткосрочных заемных обязательств может быть при необходимости погашена немедленно.

Кабс. л. 2009 = 220/6990 » 0,03

Кабс. л. 2010 = 310/8800 » 0,04

Кабс. л. 2011 = 360/9990 » 0,04

Коэффициент промежуточной ликвидности (Кпром. л.) - это отношение суммы легко ликвидных активов и дебиторской задолженности, отнесенной ко 2-й группе активов по степени ликвидности ко всем краткосрочным обязательствам предприятия:

Кпром. л. = (А1 + ДЗ)/(П1 + П2 + П3) = (А1 + ДЗ)/КО, (3)

где ДЗ - дебиторская задолженность.

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

Кпром. л. 2009 = (220 + 530)/6990 = 750/6990 » 0,11

Кпром. л. 2010 = (310 + 1090)/8800 = 1400/8800 » 0,16

Кпром. л. 2011 = (360 + 3410)/9990 = 3770/9990 » 0,38

Коэффициент общей ликвидности (Кобщ. л.) - это отношение текущих активов к текущим обязательствам:

Кобщ. л. = (А1 + А2 + А3)/(П1 + П2 + П3) = ОбА/КО, (4)

где А2 - дебиторская задолженность, готовая продукция, товары отгруженные; А3 - производственные запасы, расходы будущих периодов и незавершенное производство; ОбА - оборотные активы.

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

Кобщ. л. 2009 = 6700/6990 » 0,96

Кобщ. л. 2010 = 8440/8800 » 0,96

Кобщ. л. 2011 = 12260/9990 » 1,23

Критическая оценка ликвидности (Ккрит. л.) - это отношение текущих активов за вычетом производственных запасов, относимых к 3 группе, к текущим обязательствам:

Ккрит. л. = (А1 + А2 + А3 - ПЗ)/(П1 + П2 + П3) = (ОбА - ПЗ)/КО, (5)

где ПЗ - производственные запасы.

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

Ккрит. л. 2009 = (6700 - 320)/6990 = 6380/6990 » 0,91

Ккрит. л. 2010 = (8440 - 680)/8800 = 7760/8800 » 0,88

Коэффициент общей платежеспособности (Кобщ. плат.):

Кобщ. плат. = (ДСн + ДСпост.)/ДСнапр, (6)

где ДСн - остатки денежных средств на начало года;

ДСпост. - поступило денежных средств в течение года;

ДСнапр. - направлено денежных средств.

Кобщ. плат. 2009 = (80 + 45790)/45330 = 45870/45330 » 1,012

Кобщ. плат. 2010 = (220 + 51650)/51560 = 51870/51560 » 1,006

Кобщ. плат. 2011 = (310 + 51420)/51370 = 51730/51370 » 1,007

На основании проведенных расчетов составим сводную таблицу анализа показателей ликвидности и платежеспособности по ТОО «Казцинктех» за 2009-2011 гг.

Таблица 10 Анализ показателей ликвидности и платежеспособности по ТОО «Казцинктех» за 2008-2010 гг

Наименование показателей2009г.2010г.2011г.Отклонение, +/- 2011 г. от 2010 г.12345Коэффициент текущей платежеспособности1,050,971,16+0,19Коэффициент абсолютной ликвидности0,030,040,040Коэффициент промежуточной ликвидности0,110,160,38+0,22Коэффициент общей ликвидности0,960,961,23+0,27Критическая оценка ликвидности0,910,880,98+0,10Коэффициент общей платежеспособности1,0121,0061,007+0,001Результаты расчета показателей ликвидности указывают на достаточность ликвидных средств у ТОО «Казцинктех» для погашения краткосрочных обязательств: баланс предприятия является ликвидным, и ТОО «Казцинктех» можно считать платежеспособной. К концу 2011 г. по сравнению с 2010 г. наблюдается рост практически всех показателей (за исключением коэффициента абсолютной ликвидности - его значение осталось без изменений на уровне 0,04): коэффициентов текущей платежеспособности, промежуточной ликвидности, общей ликвидности, критической оценки ликвидности и общей платежеспособности соответственно на 0,19, 0,22, 0,27, 0,10, 0,001.

Рентабельность предприятия.

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

Для выполнения расчетов заполним таблицу 11 данными, необходимыми для определения коэффициентов, на основании бухгалтерского баланса ТОО «Казцинктех» и отчета о прибылях и убытках.

Таблица 11 Данные для расчета показателей рентабельности по ТОО «Казцинктех» за 2009-2011 гг

Наименование показателейЕд. изм.2009г.2010г.2011г.12345Выручка от реализации товаров, продукции, работ, услуг за вычетом налогов и сборов, включаемых в выручкуТыс. тг.315503401041050Общая сумма прибылиТыс. тг.250300390Прибыль от реализации товаров, продукции, работ, услугТыс. тг.270530460Чистая прибыльТыс. тг.101060Общие затраты на производство и реализацию продукцииТыс. тг.312803348040590Средняя стоимость активовТыс. тг.14900,517640,521390,5Средняя величина оборотных активовТыс. тг.5750757010350Средняя величина внеоборотных активовТыс. тг.9150,510070,511040,5Средняя величина капиталаТыс. тг.14900,517640,521390,5Средняя величина собственного капиталаТыс. тг.8350938010770,5Средняя величина перманентного капиталаТыс. тг.8980975012000

Рассчитаем показатели рентабельности по ТОО «Казцинктех» за 2009-2011 гг.

Показатели прибыльности продаж и рентабельности продукции:

Рентабельность продаж (реализации) (Rпр) - отношение прибыли к объему реализации продукции, товаров, работ, услуг:

Rпр = П/В, (7)

где П - прибыль;

В - объем реализованной продукции, товаров, работ, услуг.

Рентабельность продаж (реализации) показывает, сколько прибыли приходится на единицу реализованной продукции, товаров, работ, услуг.

По общей прибыли:

RпрПрО 2009 = 250/31550 х 100 » 0,792%

RпрПрО 2010 = 300/34010 х 100 » 0,882%

RпрПрО 2011 = 390/41050 х 100 » 0,950%

По прибыли от реализации:

RпрПрР 2009 = 270/31550 х 100 » 0,856%

RпрПрР 2010 = 530/34010 х 100 » 1,558%

RпрПрР 2011 = 460/41050 х 100 » 1,121%

По чистой прибыли:

RпрПрЧ 2009 = 1/31550 х 100 » 0,032%

RпрПрЧ 2010 = 1/34010 х 100 » 0,029%

RпрПрЧ 2011 = 6/41050 х 100 » 0,146%

Рентабельность продукции (Rпрод.) - отношение прибыли от реализации к полной себестоимости продукции:

Rпрод. = Пр/З, (8)

где Пр - прибыль от реализации;

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

Этот показатель также называют рентабельностью основной деятельности: он показывает, сколько прибыли от реализации приходится на 1 тенге затрат.

Rпрод. 2009 = 270/31280 х 100 » 0,863%

Rпрод. 2010 = 530/33480 х 100 » 1,583%

Rпрод. 2011 = 460/40590 х 100 » 1,133%

Показатели рентабельности активов:

Рентабельность активов (RА) - отношение суммы прибыли к средней стоимости активов предприятия:

RА = П/Аср, (9)

где Аср - средняя стоимость активов предприятия.

Коэффициент показывает, сколько тенге прибыли получено на 1 тенге активов.

По общей прибыли:

RАПрО 2009 = 250/1490,5 х 100 » 1,677%

RАПрО 2010 = 300/1764,5 х 100 » 1,700%

RАПрО 2011 = 390/2139,5 х 100 » 1,823%

По прибыли от реализации:

RАПрР 2009 = 270/1490,5 х 100 » 1,811%

RАПрР 2010 = 530/1764,5 х 100 » 3,004%

RАПрР 2011 = 460/2139,5 х 100 » 2,150%

По чистой прибыли:

RАПрЧ 2009 = 10/1490,5 х 100 » 0,067%

RАПрЧ 2010 = 10/1764,5 х 100 » 0,057%

RАПрЧ 2011 = 60/2139,5 х 100 » 0,280%

Показатели рентабельности финансовых источников капитала:

Рентабельность совокупного капитала (RОК) - отношение прибыли к средней величине общего капитала предприятия:

RОК = П/ОКср, (10)

где ОКср - средняя величина капитала предприятия.

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

Уровень экономической рентабельности соответствует уровню рентабельности активов.

По общей прибыли:

RОКПрО 2009 = 250/1490,5 х 100 » 1,677%

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

Необходимость создания корпоративной методологии, которая бы установила правила выполнения процессов управления проектом. Необходимо создать орган, осуществляющий методологическую поддержку руководителей проектов и контролирующий сроки выполнения проектов (УСМК), создать шаблоны необходимых, для реализации проектов, документов. Постепенно налаживается контроль за сроками выполнения проектов. Действует система инициирования и принятия решения по проектам.

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

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

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

Рис. 1 Принципиальная схема формирования и управления проектом (пирамида функций, этапов и процессов)

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

Ключевым фактором ведения проекта является методика, которая должна быть достаточно прозрачной. Первые формируются на этапах обследования и анализа задачи, а также при тестировании, вторые – являются фактом завершения этапа (между ними реализуется «процесс»).

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

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

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

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

Свердлов П.А., Вертакова Ю.В*.