Тема: Использование локальных и глобальных коммуникационных сетей для оптимизации проектных работ на примере функционирования проектного офиса Фонда прямых инвестиций «Роял- групп»

• Вид работы:
  Дипломная (ВКР) по теме: Использование локальных и глобальных коммуникационных сетей для оптимизации проектных работ на примере функционирования проектного офиса Фонда прямых инвестиций «Роял- групп»
• Предмет:
  Информационные технологии
• Когда добавили:
  17.09.2010 16:16:24
• Тип файлов:
  MS WORD
• Проверка на вирусы:
  Проверено - Антивирус Касперского

Другие экслюзивные материалы по теме

• Полный текст:
   План
  
  Введение. 4
  Обзор проектного управления, современное состояние дел. 6
  1 глава. Общие понятия проектного управления, функционирование проектного офиса. 10
  §1. Управление проектами и особенности управления инвестиционными проектами. 10
  §2. Проектный менеджмент как инструмент управления в  организации. 19
  §3. Взаимодействие участников проекта и коммуникационная среда. 22
  2 глава. Анализ  потребности и опыт  внедрения офиса управления проектами  27
  §1. Анализ условий для успешного внедрения офиса управления проектами(ОУП). 27
  §2.Обоснование выбора системы управления Портфелем проектов. 32
  §3.Организация выбора и внедрения локальной и глобальной коммуникационной сети для оптимизации проектных работ. 38
  .. 44
  3 глава. Описание внедрения и преимуществ программного комплекса по управлению проектами  Lotus Domino. 48
  §1. Преимущества от использования Lotus Domino для оптмизации проектного управления. 48
  §2. Описание архитектуры и логики построения офиса управления проектами на основе Lotus Domino 54
  Заключение. Выводы, дальнейшие перспективы развития проектного управления в России. 69
  Список использованной литературы.. 72
   
   
  Аннотация
  В дипломном работе «Использование локальных и глобальных коммуникационных сетей для оптимизации проектных работы на примере функционирования проектного офиса Фонда прямых инвестиций «Роял- групп» рассмотрен пример управления инвестиционными проектами, и возникающие в связи со спецификой управленческой деятельности проблемы взаимодействия между ресурсами, а также рассмотрены возможные варианты решения возникающих коммуникационных конфликтов, в к том числе с  помощью современных компьютерных технологий таких  как, например, ввод  в эксплуатацию системы управления корпоративными ресурсами и проектами разработанной на базе Lotus Domino, а также частично показана экономическая  целесообразность введения подобной системы, практичности ее использования и функциональность.
  Общее количество страниц с приложениями 80 . Материал приложения представлен на 11 страницах.Введение
    Управление проектами – это важнейший инструмент современного менеджмента.
  Актуальность данной темы состоит в том, что в сфере большого бизнеса требуется принятие важных решений, результат которых может стоить компании миллионы рублей, а порой даже и миллиарды долларов США. Имея под рукой нужную и достоверную информацию, руководство компаний может снизить, а порой и избежать рисков при решении управленческих вопросов.
  Объектом дипломного исследования является Фонд прямых инвестиций «Роял групп»
  Предметом исследования является анализ функционирования системы позволяющей наладить глобальную  и корпоративную коммуникацию Lotus Dominо, а также выявление запросов пользователей, и внедрение дополнительных возможностей системы в управленческом аспекте.
  Главной целью данной работы является:
  ·   Описание принципов проектного управления инвестиционными проектами,
  ·   Описание использования локальных и глобальных коммуникационных сетей в проектном управлении,
  ·   И в связи с управленческими задачами выявление основных проблем в процессе интеграции системы Lotus Domino, как системы позволяющей автоматизировать процесс управления проектами на разных его стадиях в уже существующею в компании корпоративную коммуникационною систему;
  В соответствии с поставленной целью можно сформулировать следующие задачи:
  · Описание возможных коммуникационных проблем пользователей системы Lotus Dominо и пути их оптимального решения;
  ·   Анализ результатов внедрения системы Lotus Dominо;
  Структурно дипломная работа состоит из трех глав, заключения, списка использованной литературы и двух приложений.
  Обзор проектного управления, современное состояние дел. В последнее время в проектной сфере произошли значи­тельные изменения, в частности, проек­ты перестали быть характерной чертой строительной индуст­рии, и теперь управление проектами все чаще применяется в других отраслях человеческой деятельности.
  Если говорить о развитии проектного менеджмента в XX в., то можно выделить три основных этапа:
  Первый — от начала века до 1950-х гг. В этот период масш­табные проекты реализовывались, однако не существовало общепринятых или четко выработанных методов управления проектами. Руководство проектной деятельностью осуществля­лось стихийно и опиралось на способности конкретных руково­дителей работать в экстремальном режиме. Рефлексия деятель­ности, обобщение опыта управления проектами не проводились, различия между стандартной деятельностью и проектами в ме­неджменте явно не осознавались.
  Второй — 1950-е гг. В США были разработаны так называ­емые количественные методы управления для реализации круп­ных проектов. Суть их сводилась в основном к выбору на ос­новании расчетов «одного наилучшего способа» реализации де­ятельности.
  Третий — 1990-е гг. Именно в это время возник гибкий, динамичный подход к управлению проектами, основанный на учете возможных условий и ограничений, опирающийся на раз­работку стратегии деятельности.
  Сегодня управление проектами считается передовой спе­циализированной отраслью менеджмента, отдельной уп­равленческой специальностью, сущность которой состоит в обеспечении осуществления проекта от стадии разработ­ки стратегии до этапа практического осуществления. Жест­кие количественные методы, трактовавшие реализацию про­екта как чисто механическую, «просчитываемую» деятельность с одним «правильным» путем реализации, показали свою не­состоятельность.
  Еще раз повторим: очевидно, что как небольшие, так и крупные проекты осуществлялись и до 1950-х гг. прошлого века. Отдельные талантливые руководители успешно осуще­ствляли сложные мероприятия, создавали новые продукты и  справлялись с непростыми ситуациями. Но общих законо­мерностей успехов или неудач, а также особенностей их деятельности никто не искал, управления проектами в том виде, в каком мы рассматриваем его сегодня, не существовало в принципе, положительные или отрицательные результаты при­писывались индивидуальным особенностям руководителей или специфике ситуации.
  В 1950-х гг. были разработаны формальные методы, пред­назначенные для оказания помощи в управлении крупными комплексными проектами, которые осуществлялись в услови­ях высокой неопределенности и риска. Например, химический концерн Du Pont разработал так называемый метод анализа критического пути (СРА) для составления графика закрытия своих производственных мощностей на период проведения профилактического ремонта. В это же время крупный подряд­чик Министерства обороны RAND Corporation создал метод оценки и пересмотра планов (PERT), предназначенный для планирования развития ракетной промышленности. Особен­ность этих методов состояла в том, что они уделяли главное внимание фазе планирования проекта и касались в основном составления и корректировки планов. Они в целом доказали свою состоятельность, хотя никогда не сопоставлялись с дру­гими методами по параметру эффективности, поскольку кон­куренции в этой сфере не было.
  Изобретение комплекса методов под общим названием СРА приписывается разным авторам. Однако точно известно вре­мя его первого применения, датируемое 1957-1958 гг. Счита­ется, что первыми разработчиками и пользователями данного метода были Catalytic Construction Company (использовавшая СРА для планирования и контроля строительного проекта, выполнявшегося по заказу Du Pont Corporation), Du Pont Consulting и персонально Дж. Келли из Remington-Rand и М. Уолкер из Du Pont.
  Суть этого метода сводится к построению сетевого графи­ка, позволяющего достаточно точно рассчитать время начала и сроки отдельных конкретных работ, необходимые для того, чтобы завершить проект в запланированное время.
  Традиционные методы, разработанные для управле­ния масштабными капиталоемкими проектами со сроками реализации в несколько лет, например, в тяжелом машиностро­ении, оказываются слишком громоздкими и медленными, по­скольку сегодня проекты должны осуществляться в короткие сроки, чтобы быстрее использовать рыночные возможности, в особенности в странах, где экономика характеризуется высо­ким уровнем конкуренции и распространения информации, что все более и более характерно для современной России.
  На третьем этапе развития управления проектами, начиная с 90-х гг. XX в., акцент делается на стратегическом управле­нии, в особенности на тех процессах, которые менеджер про­екта должен осуществлять для достижения конечной цели проекта и удовлетворения потребностей заказчика и всех за­интересованных лиц. При таком новом подходе менеджеры проекта выполняют интегрирующую функцию, отвечая за со­гласованное использование требующихся ресурсов, обмен зна­ниями и координацию действий с начала проекта и до мо­мента его завершения.
    Третий этап развития представлений об управлении про­ектами во многом связан с осознанием изменений, произошед­ших в условиях реализации современных проектов. В частно­сти, высокий уровень развития технологий (в особенности коммуникационных) и связанная с этим доступность инфор­мации привели к созданию так называемых виртуальных групп управления проектами, чаще всего называемых Проектный офис, или Офис управления проектами также встречаются аббревиатуры Проектный центр, одна из таких систем  будет описана в данной дипломной работе. Значительные изменения про­изошли также и в процессе планирования крупных проектов, и в их программно-техническом обеспечении, связанном с воз­можностями компьютерной обработки информации. Достиже­ния в этих областях способны значительно повлиять на про­цесс работы над проектами.
  Эти соображения по поводу эволюции управления проек­тами подводят нас к проблемам, с которыми сталкиваются сегодня компании применяющие на практике в своей управленческой деятельности принципы проектного управления таких, как например фонд прямых инвестиций «Роял Групп».
   
   
  1 глава. Общие понятия проектного управления, функционирование проектного офиса. §1.  Управление проектами и особенности управления инвестиционными проектами. В настоящее время имеется достаточно полно разработанная теория управления проектами. Более того, разработан и активно применяется на практике международный стандарт по управлению проектами — ANSI PMI РМВОКGUIDE 2004 (Свод знаний по управлению проектами) В стандарте PMI PMBOK сведен воедино опыт и лучшие практики тысяч квалифицированных проектных менеджеров всего мира. Принципы стандарта позволяют эффективно планировать проектную деятельность, управлять в рамках проекта изменениями и рисками, бюджетом, командой.
  Проект — это комплексное, не повторяющееся мероприятие предполагающее внедрение нового, ограниченное по времени, бюджету, ресурсам, а также четкими указаниями по выполнению, разработанными под потребности заказчика. Так как объектом исследования дипломной работы является фонд прямых инвестиций «Роял Групп» рассмотрим также определение  инвестиционного проекта, инвестиционный проект —последовательность действий, связанных с обоснованием объемов и порядка вложения средств, их реальными затратами, введением мощностей в действие, текущей оценкой целесообразности проекта и итоговой оценкой результативности проекта по его завершении, проект намечаемый к планомерному осуществлению, объединение единой целью и приуроченный к определенному времени комплекс работ и мероприятий по созданию, производству и продвижению на рынок новых высокотехнологичных продуктов с указанием и исполнителей, используемых ресурсов и их источников.
  Единого определения понятия «управление проектом» официально не существует.
  Вот несколько определений, которые наиболее полно отражают суть предмета.
  Управление проектом (УП;project management, PM) — этой искусство руководства и координации людских и материальных ресурсов на протяжении жизненного цикла проекта путем применения современный методов и техники управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, вре­мени, качеству и удовлетворению участников проекта[1].
  Управление проекта­ми — это управленческая задача по завершению проекта в срок, в рамках установленного бюджета и в соответствии с техническими спецификациями и требованиями. Проект-менеджер является от­ветственным за достижение этих результатов[2] .
  Управление проектом — это един­ство управленческих задач, организации, техники и средств для реа­лизации проекта[3] .
  Итак, если обобщить вышеперечисленные определения, то основными признаками проекта являются: 1) новизна; 2) изменения как основное содержание проекта; 3) неповтори­мость; 4) конкретная цель, ограниченная во времени; 5) временная ограниченность продолжительности проекта; 6) ограниченность требуемых ресурсов; 7) бюджет, относящийся к проекту; 8) комп­лексность решения проблемы; 9) выделение сферы проекта в сфе­ре взаимодействия организации и рынка.
  В качестве примеров можно привести такие проекты, как инвестирование в строительство микрорайона с созда­нием необходимой инфраструктуры, оптимизация энергопотреб­ления области, создание и обеспечение выпуска нового автомоби­ля, модернизация предприятия, реорганизация коммунального хозяйства города.
  Очевидно, что  для управления проектами необходимы рычаги управленче­ского воздействия. К основным рычагам управления можно отнес­ти ресурсы проекта и используемые технологии, к примеру, в данной дипломной работе будет рассмотрена система Lotus Domino как объект глобальной и локальной коммуникационной сети, предназначенная для координации управления и оптимизации процесса принятия важных управленческих решений. Функции же управления определяются содержанием и жизненным циклом проекта.
  Жизненный цикл инвестиционного проекта в точки зрения фонда прямых инвестиций это — полный комплекс работ и мероприятий, выполняемых в строго определенной последовательности всеми исполнителями проекта. Таким образом, жизненный цикл проекта охватывает все стадии его воплощения — от появления замысла и проведения проектного комитета на котором утверждается перспективность предложенной идеи и анализируется целесообразность инвестирования в данный проект, и подготовки инвестиционного меморандума, так часто и до подготовки непосредственного производства и участия в производстве продукции и реализации. В него могут входить послепродажное обслуживание, эксплуатация, а иногда утилизация продукта.
  У проекта обязательно име­ются одна или несколько целей, достижение либо не достижение которых является показателем успешности проекта, фонд «Роял Групп» как правило, принимает за достижение цели, получение инвестиций на наиболее выгодных для фонда условиях.
  Следует различать принципы линейного управления и проектного, хотя и то и другое часто очень связано и направлено на решение управленческих задач, грань бывает еле различимой, особенно с высоты владельца бизнеса, но данный аспект различия является ключевым  в понимании  принципов проектного управления. Проект с точки зрения современной теории управления, имеет следующие характеристики и отличается от линейного управления следующим:
  •   любая неповторяющаяся деятельность;
  •   многоплановая деятельность, осуществляемая в небольшом объеме;
  •   ограниченное во времени мероприятие по созданию уни­кального товара или услуги;
  •   любая деятельность с фиксированными сроками начала и завершения;
  •   совокупность скоординированных действий, имеющих уни­кальный характер, с запланированными сроками начала и конца их осуществления, предпринимаемых человеком или организацией для достижения конкретных целей в преде­лах установленных сроков и с заданными показателями затрат и результатов.
  Еще одна важнейшая характеристика проекта — он наце­лен на изменения, данная характеристики применима  в равной степени и к проектам инвестиционным. Рассмотрим пример, как на практике работает данная характеристика: представим себе деятельность некой организации, например завода. У него есть определенный производственный цикл, есть иерархическая система управ­ления. Каждый из работников имеет четко регламентирован­ные обязанности и исполняет в соответствии с ними конк­ретные, постоянно повторяющиеся процедуры. Безусловно, такая деятельность не является проектом – это обычная операционная деятельность любого предприятия и как правило управляется линейно. Однако если принято решение осваивать выпуск нового вида продукции, внедрять новые технологии, оптимизирующие деятельность, то в этом случае уже можно говорить, что за­вод будет реализовывать некий новый проект, потому что существует идея внесения изменений в налаженную систе­му деятельности. Кроме того, что касается результатов проекта, то они мо­гут быть масштабными и грандиозными с качественной точ­ки зрения, однако с точки зрения объемов, количественных характеристик проект не всегда бывает глобальным, что очевидно при рассмотрении инвестиционных заявок. Результат почти всегда связан с определенными изменениями в системе работы организации, с внедрением нового вида деятельности, товара, услуги, и масштабность замыслов часто прихо­дит в противоречие с качеством результата. Рассмотрим  другой пример, и как может показаться на первый взгляд, что данный пример это исключение из правила «новизны».
  Пример[4]
  Сегодня во всем мире широко распространена система Fast Food. Безусловно, многие специалисты считают ее вредной для здоро­вья, однако реальность такова, что люди во всем мире этой си­стемой активно пользуются. Пионером в этой области считается, вероятно, американский McDonald's. Так вот, если рассмотреть ситуацию в ретроспективе, то, безусловно, при становлении сети (набор блюд, технологии приготовления и хранения, система об­служивания клиентов, внутрикорпоративные отношения и пр.), на первом этапе реализации идеи имели характеристики про­екта (этого не было ранее, это было внедрение нового). А вот сегодня деятельность этой сети уже не имеет характера проек­та, поскольку строится на внедрении отработанных технологий. Однако разнообразия и непредсказуемости в деятельности фир­мы нет, набор блюд и услуг, система обслуживания стандартны по всему миру.
   Для менеджера управляющего проектом очень важно четко по­нимать: важна именно качественная оценка результата, а не ко­личественная. Объемы появятся на этапе внедрения нового, когда новая деятельность будет приобретать черты традицион­ности.
    И из этого примера, да и хорошо знаем из практики что, опыт Макдональдс активно применяется и тиражируется по всему миру.
  Объем производства и обслуживания в этих сетях грандиозен, это по сути своей поток, когда компании в огром­ном количестве воспроизводят свои фирменные блюда, обслу­живая миллионы людей.
  Таким образом, традиционный подход в теории управле­ния проектами рассматривает их двояко:
  •   ограниченные в масштабах, но весьма разнообразные про­цессы, и здесь понятие уникальности, первичности, стано­вится основным;
  •   тиражирование процессов с отдельными частными отличи­ями в результатах или тиражирование результатов на ос­нове корректировки или оптимизации процессов.
  В теории управления проектами первые носят название «создаваемых впервые». Схема может выглядеть следующим образом: есть некая потребность, и проект состоит в поиске и отработке новых, ранее не существовавших оптимальных пу­тей ее удовлетворения. В рассмотренном выше примере с системой Fast Food этой потребностью была потребность в высвобождении времени и сил работающего человека, в том числе и от решения бытовых проблем.
  Вторые образно называют «как и...,но...», т. е. как выпол­няли работу прошлый раз, но с некоторыми отличиями. В итоге поиска путей решения по всему миру появились пиц­церии, McDonald's'ы, «Чайные ложки» и «Самовары»,  в которых люди могут быстро  пообедать во время ко­роткого перерыва в работе и даже взять еду домой. То есть второй тип проектов был связан с тиражированием уникаль­ных результатов первичного проекта и внесением некоторых новых черт в качественные характеристики продукта.
  К таким, не создающих уникальных результатов проектов относятся:
  •   финансовый аудит компании (основывается на конкретных условиях, но процессы и результаты — отчеты аудиторов — хорошо известны);
  •   проведение маркетинговых исследований (в сущности — воспроизведение на основе большого числа повторений, по­скольку данное конкретное исследование уникально, но во­обще технология таких исследований прекрасно известна).
    Есть и другие типологии проектов, не ориентированные на степень уникальности результата, как та, которая рассматривалась выше. Такие проекты подразделяют на операци­онные — создающие новые объекты, непосредственно прино­сящие доход, и организационные, т. е. предусматривающие проведение изменений — совершенствование способов рабо­ты организации в целом или ее сотрудников.
  При всех условиях независимо от типологии сущность всех проектов связана с изменениями, касающимися либо спосо­бов деятельности, либо ее результатов.
    В фонде прямых инвестиций «Роял Групп» рассматриваются и принимаются любые проекты по типологии, но перспективные с точки зрения инвестиций. В настоящее время в России сложились необходимые и доста­точные предпосылки для создания системы инвести­рования в инновационный сектор российской экономики. Чтобы выжить в условиях жесткой конкуренции, организациям сегодня постоянно приходится меняться. Эти изменения связаны, как и  с видами деятельности и способами ее осуществления,  так  и с расширением перечня товаров и услуг, и  изменением самое важное  способов управления. Как показывает практика, наиболее успешными оказываются те, кто лучше других приспособился к жизни в постоянно меняющихся условиях и умеет меняться быстро и эффективно. В такой ситуации выжить и достичь конкурентоспособных результатов можно, прежде всего за счет хорошей организации менеджмента, одной из важнейших составляющих которого является управление проектами.
   
  §2. Проектный менеджмент как инструмент управления в  организации. Проект — это всегда процесс деятельно­сти, и соответственно управление проектом — это управление процессом, однако процессом во многом не регламентирован­ным, не алгоритмизованным, некоторые особенности которо­го не всегда удается предусмотреть заранее. И в этом — одна из сложностей управления проектами. А также исполнители, заказчики и инвесторы работ являются участниками проекта. И как участники проекта они поставлены в условия, когда для эффективного выполнения проекта они должны выстроить коммуникации между собой. На уровне здравого смысла даже те, кто не являются спе­циалистами в области управления, знают, что любая деятель­ность нуждается в организации и контроле, т. е. в управлении.
  Эволюция систем управления проектами включает три фазы:
  1) случайное использование;
  2) формальное применение «материнской организации»;
  3) организации, ориентированные на проекты.
  Процессы управления проектом определяются жизненным циклом проекта и зависят от области его приложения. Процессы управления проектами могут быть разбиты на шесть основных групп: 1) процессы инициации — от формулирования идеи до при­нятия решения о начале выполнения проекта; 2) процессы плани­рования — определение целей и критериев успеха проекта и раз­работка рабочих схем их достижения; 3) процессы исполнения — координация людей и других ресурсов для выполнения плана; 4) процессы анализа — определение соответствия плана и испол­нения проекта поставленным целям и критериям и принятие решений о корректирующих воздействиях; 5) процессы управле­ния — определение корректирующих воздействий, их согласова­ние, утверждение и применение; 6) процессы завершения — фор­мализация выполнения проекта и подведение его к упорядочен­ному финалу.
  Ключевыми участниками любого проекта являются ини­циатор проекта, руководитель проекта, покупатель (потребитель), команда проекта, инвестор и заказчик (владелец). Инициатор про­екта — это генератор и главный «проталкиватель» идеи. Руководи­тель проекта — лицо, ответственное за управление проектом. По­купатель (потребитель) — лицо или организация, использующая продукт проекта. Команда проекта — группа исполнителей или организация, сотрудники которой непосредственно вовлечены в исполнение проекта. Инвестор — лицо, группа или организация, предоставляющая финансовые ресурсы для исполнения проекта. Заказчик (владелец) — лицо или организация, которые являются будущими собственниками результатов проекта. В успешном за­вершении проекта заинтересованы все участники, реализующие таким образом свои индивидуальные интересы:
  • инвесторы в этом случае возвращают вложенный капитал и получают установленные дивиденды;
  • заказчик (владелец, клиент) получает реализованный проект и доходы от его использования;
  • руководитель проекта и его команда получают плату по конт­ракту, дополнительное вознаграждение по результатам работы и от прибыли; кроме того, повышается их профессиональный рейтинг;
  • органы власти получают налоги со всех участников, удовлет­воряются общественные, социальные и экологические нужды и требования на вверенной им территории;
  • потребители получают необходимые им товары, продукты и услуги, плата за которые возмещает расходы на проект и обра­зует прибыль, получаемую активными участниками проекта;
  • другие заинтересованные стороны тоже достигают своих целей.
  Одной из главных сфер ответственности руководителя яв­ляется  успешность выполнения проекта.
  §3. Взаимодействие участников проекта и коммуникационная среда. Как отмечалось ранее, руководитель проекта является ответственным за  успешное выполнение проекта, так  как в зоне его ответственности лежит выбор команды проекта и построение эффективной коммуникации между ними. Так, например,  опыт внедрение проектного управления в фонде прямых инвестиций «Роял групп», в части принятия стратегических решений в отношении финансирования проектов поступающих в фонд от сторонних организаций либо инициированных внутри фонда, показал насколько важна коммуникационная среда для принятия управленческих решений.  На стадии инициации проекта от заказчика со стороны фонда назначается  так  называемый инициатор, который принимает и оформляет первичную документацию по будущему проекту, он также помогает готовить все необходимые аналитические записки и бизнес отчеты, для того, чтобы проект успешно прошел стадию инвестиционного комитета, на котором  приглашенные эксперты путем голосования большинством голосов одобряют или отвергают проект. В дальнейшем, он, как правило и назначается на должность руководителя проекта и несет ответственность за успешное выполнение проекта.  Сложилась следующая ситуация, что как правило, назначался человек помимо работы над проектом у которого имеются свои обязательные для каждодневного выполнения должностные обязанности, и человек воспринимал назначение его на проект как некоторый факультатив. По мере роста проектов начали возникать проблемы административного характера,  не было «прозрачности» управления, которое бы устраивало высшее руководстве, на уровне которого принималось решение, полноты исполнения, а главное универсальность и актуальность отчетности проследить не представлялось возможным. Линейные руководители, находящиеся, казалось бы, в шаговой доступности друг от друга в силу загруженности операционными задачами  не взаимодействовали друг с другом, что вызывало совершенное неэффективное выполнение проектов  порой почти «преступно» и часто с большими убытками для компании, потому что срывались сроки, либо проекты выполнялись абы как без надлежавшего качества выполнения. Возникли явные проблемы в коммуникации между участниками проектов, руководителя проектов и руководством. Остановимся в данной связи на определении  коммуникации. Коммуникация от лат. Communico( делаю общим) - в широком смысле - обмен информацией между индивидами через посредство общей системы символов. Коммуникация может осуществляться вербальными и невербальными средствами. Различают механистический и деятельностной подход к коммуникации. Коммуникация - в механистическом подходе - однонаправленный процесс кодирования и передачи информации от источника и приема информации получателем сообщения. Коммуникация - в деятельностном подходе - совместная деятельность участников коммуникации (коммуникантов), в ходе которой вырабатывается общий (до определенного предела) взгляд на вещи и действия с ними.  В связи с этим в поле управленческого зрения попадает термин communication strategy(коммуникационные стратегии)  этот термин имеет разнообразные трактовки в зависимости от соответствующих областей применения и школ управления, можно выделить два основных  практических применения: во-первых, это план коммуникации на определенный, зачастую долгосрочный, период времени; а, во-вторых, это определенные принципы построения коммуникации в каком-то конкретном проекте. Активная коммуникация рассматривается как ключевой фактор улучшения позиции и поведения сотрудников и обмен информацией внутри организации. Для эффективной работы всей организации жизненно важно наладить доступ к информации тех, кто в ней нуждается. Например, бухгалтерия не сможет эффективно работать и подсчитать заработную плату без информации о графике работы служащих. В этом смысле организации можно представить как системы обмена информацией. Сокрытие информации, то есть отсутствие коммуникации, может являться сильным орудием власти над другими работниками организации. Если руководитель не в курсе последних событий, он не сможет влиять на принятие решений или на деятельность организации в целом. Часто возникают препятствия для эффективной передачи информации. По мере продвижения по организации сверху вниз информация может быть модифицирована, как результат недопонимания или личных предрассудков исполнителей, то есть когда информация достигает точки назначения, она может к этому времени сильно измениться. Эффективная коммуникация также требует времени, это еще одна трудность. Все усилия, предпринимаемые по передаче информации, в конечном счете оправдывают себя, так как работник, лишенный надлежащих источников, чувствует неудовлетворенность своей работой и у него пропадает мотивация труда. В результате страдает производственный процесс.  Считается, что плохие отношения на производстве являются результатом отсутствия коммуникации. Возможно, это случайность, но проблемы в отношениях на производстве и споры возникают из-за объяснимой разницы в интересах, которую можно устранить при помощи коммуникации. В добавление к этим поведенческим аспектам коммуникации за последние десять лет коренным образом изменился процесс или технология коммуникации появились и прочно утвердились такие понятия как глобальные и локальные коммуникации. Например, традиционная система телефонной связи (использующая установленный телефонный аппарат, соединенный с сетью проводами) заменена сейчас на беспроводную связь (мобильные телефоны), появились и другие новшества, например регистрация устных сообщений.
  Более того, многие компании подключили свои ПК (персональные компьютеры), компьютерные и телекоммуникационные сети к добавочным услугам сети, каковой, например, является электронная почта E-mail (проведение видеоконференций и электронный обмен данными). Эти достижения технического прогресса не только ускорили коммуникацию и сделали ее более эффективной.
  Коммуникация считается успешной, если получатель информации понимает ее содержание адекватно тому смыслу, который в нее вложил отправитель. Схема внутриорганизационных коммуникаций изображена на рис. 1.
   
   
  
   
   
  рис. 1. Менеджер как информационно-коммуникативный центр
  Однако нередко внутриорганизационными коммуникациями пренебрегают. Это происходит по нескольким причинам, среди которых – нехватка времени у руководителей (важные проекты, давящие сроки, встречи и т. д.), общая перегруженность деловой информацией, а также многолетняя, если не многовековая, традиция однонаправленных связей сверху вниз.
   
   
  Рис. 2. Коммуникативный процесс
   
   
  Рис. 3. Классификация коммуникативных каналов по пропускной способности
   
  Эффективность коммуникаций может быть различной. По данным исследований результативность горизонтальных связей достигает 90%, вертикальных – 20–25% (такое количество исходящей от руководителей информации доходит до работников и правильно понимается ими). Другими словами, исполнители способны реализовать свои функции, располагая лишь пятой частью предназначенной им информации.
  Недостаточную эффективность вертикальных (как восходящих, так и нисходящих) коммуникаций подтверждают данные о том, что ближайший начальник рабочих (бригадир), покидая кабинет первого руководителя предприятия, выносит только 30% информации, а начальник цеха – около 40%. Коммуникации снизу вверх еще более неэффективны, так как до начальства доходит не более 10% информации. Это убедительно свидетельствует о том, что не используются все возможности в организации коммуникаций.
  Важно  в этой связи помнить и то, что эффективность коммуникаций зависит и от того, как построено сообщение.
   
  Чтобы выбранный канал глобальных или локальных коммуникации был эффективным, следует учесть ряд моментов:
  · Важно установить четкие критерии для определения информации, которая подлежит распространению среди персонала;
  · На какие профессиональные и социальные группы можно разбить работников;
  · Как наладить организационные коммуникации с отдаленными подразделениями компании;
  · Каким образом  получается информация.
  · Как налажены внутрифирменные коммуникации в российских компаниях;
  ·  Какие виды используются.
   Например, в фонде  накоплен богатый опыт в этой сфере: отработана и хорошо функционирует система электронного документооборота, внедряется система управления и оценки по ключевым показателям эффективности, проведена большая работа по делегированию полномочий на разных уровнях ответственности. Используются  онлайновые технологии которые позволяют обеспечивать  синхронный обмен информацией в реальном времени, а также оффлайновые технологии - средства электронной коммуникации сообщений в сетевом информационном пространстве, допускающие существенную асинхронность в обмене данными и сообщениями. Оффлайновые технологии включают: списки рассылки, группы новостей, веб-форумы и т.д.
  Так как процесс управления является органически связанным со всеми аспектами деятельности предприятия, то стоит в свете рассмотрения вопроса коммуникации и ее прикладных методов в виде глобальных и локальный коммуникационный сетей затронуть причины, которые выдвигаются в качестве объяснения тех или иных срывов в реализации проектов,  а это — жалобы на ограниченность ресурсов, недостаточную квалификацию исполнителей, возникновение неблагоприятных ситуаций внешнего характера (например, нужные люди были сняты руководством с проекта, потому что потребовалось их участие в других работах). Безусловно, все эти причины вполне могут объяснить, почему проект был со­рван. Но они не могут объяснить другого:
  •   Почему изначально, еще на этапе замыслов, не был опре­делен, пусть не с точностью до рубля, но в то же время более или менее реальный бюджет проекта?
  •   Почему при планировании проекта не были изначально ого­ворены квалификационные характеристики работников, не­обходимые для его реализации?
  •   Почему в планировании занятости конкретных работников возникла неразбериха?
  Ответы на эти и другие «почему» — прежде всего в недо­четах планирования работы над проектом и в недостаточной его соотнесенности с общей стратегией организации. Таким образом, проекты терпят неудачи из-за конфликта ресурсов, когда у организации есть ограниченные возможности (финан­совые, кадровые, производственные) и их сложно распреде­лить между несколькими реализуемыми одновременно про­ектами. Что это значит? А значит это, что в организации не отработан механизм для рационального распределения и ко­ординации ресурсов. Почему же этот важнейший механизм отсутствует? Прежде всего потому, что каждый конкретный проект реализуется как бы самостоя­тельно, в отрыве от других и без учета общей стратегии орга­низации. В итоге можно сказать, что, выстроив такую цепоч­ку, важно понимать: проектный менеджмент — самостоятель­ная область знания, и он опирается на свои собственные прин­ципы, подходы, технологии, которым нужно учиться, которые важно осваивать.
  Сегодня одному человеку зача­стую приходится в своей деятельности объединять  две управленческие специальности — традиционное управление и  управление проектами. Мировая статистика утверждает, что в области управления, особенно в крупном бизнесе, эти два менеджерские «дисциплины» в работе одного профессиональ­ного управленца соотносятся в пропорции 1:1. Вот поэтому гибкость, лабильность — важная черта успешного менеджера, которому важно переключаться с одних способов деятельности на другие.
  2 глава. Анализ  потребности и опыт  внедрения офиса управления проектами §1. Анализ условий для успешного внедрения офиса управления проектами(ОУП). Между успешными и неудачливыми руководителями имеется всего одно, но существенное различие - одни из них умеют управлять, а другие нет. Руководитель должен уметь добиваться успеха как в обеспечении текущих результатов работы организации, так и в проведении мероприя­тий по ее совершенствованию. ОУП призван оказывать содействие руко­водителям в решении задач развития организации.
  Руководители функциональных подразделений постоянно оценива­ются высшим руководством, коллегами и подчиненными по их способно­сти быстро добиваться требуемых результатов. Обычно хорошим считают руководителя, способного добиться ощутимых результатов в течение квартала, если не считанных недель. В противном случае возникает мне­ние о том, что у него имеются проблемы с управлением. Поэтому каждо­му руководителю приходится сталкиваться с двумя основными вопроса­ми, связанными с управлением проектами:
  • Сколько важных проектов способно выполнить руководимое им под­разделение в течение года?
  • Насколько быстро оно сумеет выполнять каждый из этих проектов?
  Выполнение многих проектов требует участия многих подразделений и функциональных служб предприятия. При этом зачастую оказывается, что управленческие приемы и процессы, используемые в отдельных подразделе­ниях и показывающие хорошие результаты на этом уровне, плохо сочетаются между собой, когда требуется совместная работа функциональных служб.
  Исходя из необходимости лучшей координации и обеспечения пред­сказуемости результатов проектов, Совет директоров Роял Групп предложил учредить ОУП для наблюдения за работами по всем реализуемым проек­там и ведения отчетности. Было также предложено, чтобы ОУП распола­гался вблизи офиса генерального директора общества, чтобы получать поддержку и помощь с его стороны.
  Хотя на бумаге идея создания ОУП выглядела привлекательно, выбран­ная стратегия не учитывала сложности такого организма, каким является фонд прямых инвестиций. При наличии порядка 75 различных инвестиционных предложений, а также тысяч добровольных исполнителей, которые приносят проекты в венчурный фонд (аффелированная структура фонда прямых инвестиций), требование о выполнении всех проектов на ос­нове единых принципов управления и введение централизованной отчетно­сти неизбежно должно было вызвать культурный шок в организации. Поэто­му было принято решение о том, что поначалу офис будет скорее консульта­ционным, нежели надзирающим органом. Миссия ОУП в этой связи была сформулирована следующим образом: «Посредством консультирования ко­манд исполнителей проектов, ОУП должен содействовать распространению и внедрению передового опыта управления проектами внутри компании и, тем самым, содействовать успешной работе организации в целом».
  Вооружившись возложенной на него миссией, ОУП приступил к соз­данию справочной информационной базы для внутренних пользователей. Команды исполнителей проектов на собственном опыте убедились в по­лезности консультационной помощи со стороны ОУП, которая способст­вовала также успешному закрытию проектов. Поскольку статус ОУП стал скорее консультативным и оперативным, то офис был переподчинен и стал отчитываться о своей ра­боте не перед генеральным директором, а перед  советом партнеров.
  Создав устойчивую клиентскую базу и добившись того, что команда исполнителей проектов начали применять принципы управления проектами существующие в инвестиционном портфеле компании, ОУП получил возможность расширить область своей деятельности и приступил к внедрению типового жизненного цикла проектов, наряду с соответствующими проформами, обучения исполнителей применению типовых форм документации. Внедрению унифицированного жизненного цикла проектов в первую очередь содействовал непосредственно генеральный директор фонда, который, совместно с финансовым директором, занимался вопросами финансирования всех проектов. Поэтому теперь, чтобы получить финансирование, все проекты должны были выполняться в соответствии с единым жизненным циклом, до внедрения которого отсутствовал стандартизованный подход к их финансированию. Жизненный цикл четко определил основные этапы и стадии проекта, начиная с его открытия и кончая реализацией обслуживания созданной в результате выполнения проекта продукцией. В отличие от многих других стандартизованных требований, установлен жизненного цикла проектов носит рекомендательный характер. Реализация этих рекомендаций не усложняет процесс выполнения проектов и не выходит за пределы делового здравого смысла.
  Хотя командам исполнителей проектов нравится предоставленная свобода, тем не менее, большинство из них предпочитает использовать рекомендуемые формы документов, поскольку они повышают эффективность работы. Это особенно справедливо в отношении тех форм и простых инструкций по их заполнению, которые можно получить с помощью собственной компьютерной сети фонда. Например, если проект требует привлечен: внешних поставщиков, то гораздо проще воспользоваться рекомендуемые формами заявок на подачу предложений и бланками контрактов, нежели всякий раз придумывать их заново. Такие формы служат просто рабочими инструментами и пользуются поддержкой со стороны членов Общества.
  Приняв предложенный типовой жизненный цикл проектов, команда исполнителей проявляют больше желания следовать ему при выполнении проектов и требуют от ОУП оказания помощи в его применении. В ответ на эти требования, ОУП был уполномочен вести реестр проектов и  периодически отслеживать ход их выполнения. Следует  отметить что, не требуя представления стандартных отчетов о ходе выполнения проектов, сотрудники ОУП периодически встречались с командами исполнителей, обсуждали вместе с ними текущее состояние дел и вносили, соответствующие поправки в реестр проектов.
  В настоящее время ОУП отслеживает графики выполнения, стоимость, риски проектов с периодичностью раз в неделю, используя для этого простые  табличные формы в формате Excel. Полученные данные вводятся в ре­естр проектов для анализа и уточнения руководством приоритетности тех или иных проектов. ОУП также проводит регулярное обучение исполнителей применению типового жизненного цикла проектов и оказывает по запросам консультационную помощь руководителям проектов в таких областях, как:
  •   составление технических заданий на проекты;
  •   выбор поставщиков и заключение контрактов с ними;
  •   жизненный цикл проектов и стандарты на разработку программных средств;
  •   управление проектными рисками;
  •   планирование проектов.
  Для управления работой ОУП был установлен набор ежегодно пла­нируемых и оцениваемых показателей, удалось добиться прогресса и экономии в следующих областях:
  •   объединение проектов создания программных средств одинакового на­значения, выполнявшихся разными рабочими группами и, таким обра­зом, устранение дублирования работ;
  •   координация деятельности более 20 рабочих групп,
  •   "совершенствование планирования различных инициатив и улучшение обоснованности технических заданий, что позволило улучшить выпол­нение проектов и повысить число новых заявок;
  •   разработка стандарта, устанавливающего самые современные требова­ния к разработке документации на программные средства и контракты с поставщиками, который гарантирует надлежащий сбор и хранение ин­формации в компьютерных системах для последующего использования;
  •   применение параметрических методов при выполнении практически всех проектов создания программных средств, позволяющих незави­симо оценивать размеры проекта и помогающих вести переговоры с заемщиками;
  •   определение реальных затрат на заработную плату исполнителей проектов (и, соответственно, сокращение годовых текущих расходов), кото­рые до введения реестра проектов не удавалось точно установить
  По прошествии двух лет становится нормой применение методов управления проектами и участие ОУП во всех проектах фонда. Ныне ОУП ищет свое место в координировании проектов, выполняемых несколькими рабочими группами, а также оказании помощи при управлении проектными рисками в масштабах  фонда. Вместе с тем, при создании ОУП в неявном виде присутст­вовало намерение со временем ликвидировать это образование. Возвра­щаясь к заявленной миссии ОУП, напомним, что он был создан ради «...содействия внедрению передового опыта управления проектами...». Таким образом, по мере того, как комитеты и рабочие группы  ста­нут все шире применять принципы управления проектами в своей повсе­дневной практике, потребность в консультативной помощи со стороны ОУП будет снижаться. Но потребуется выполнять большее количество успешных проектов, более четко определять приоритеты различных про­ектов и лучше координировать их выполнение. И скорее всего ОУП будет расформирован и занятые в нем специалисты будут заняты как планируется в перспективе бизнес планированием.
  §2.Обоснование выбора системы управления Портфелем проектов. Всякий ОУП ищет пути оптимизации методов управления проекта в той области, которую он обслуживает в нашем случае это весьма специфическая сфера деятельности, связанная в первую очередь с защитой от инсайда информации которую доверяют фонду при разработке инвестиционного меморандума. Для этой цели он может приобретать самые современные средства корпоративного управления проекта , которые стоят многие сотни тысяч долларов. ОУП может так же применять средства визуализации данных о выполнении проектов в реальном времени. Все эти возможности следует рассматривать.
  Приемлемость современных средств управления проектами для пользователей зависит уровня зрелости предприятия в области управления проектами. Очень часто на предприятиях, где уровень такой зрелости невысок, применение сложных средств управления проектами встречает сопротивление сотрудников. С утверждение особенно справедливо применительно к тем функциональным подразделениям, которые пользуются на предприятии известной автономией в части управления собственной работой. Подобное сопротивление подстегивается борьбой между функциональными подразделениями за право пользования общими ресурсами предприятия. Во всякой организации всегда есть подразделения, работающие лучше других или пользующиеся большей любовью со стороны руководства. Сложившаяся неофициальная иерархия  дает политические стимулы для отстающих брать пример с передовых подразделений. Таким образом, политическая ситуация внутри организации предпочтения ее руководителей влияют на то, применение каких средств методов поощряется и считается более приемлемым.
  Таким образом, ОУП обязан начинать свою деятельность с изучения особенностей и потребностей всех функциональных подразделений предприятия, чтобы знать, что происходит в каждом из них.
   До внедрения системы управления проектами  многие функциональные подразделения были перепол­нены разнообразными данными. Они просто тонули в них и не способны  были отсеять нужные им сведения и преобразовать их в полезную для себя ин­формацию, в нашем случае это добавляло еще работы и службе собственной безопасности.
  Как правило в организациях любого типа, коммерческих и некоммерческих, их функциональные подразделения ежедневно конкурируют друг с другом. Борьба в основном ведется за обладание редкими, ограниченными ресур­сами или вокруг того, что и как следует менять в организации. Когда речь заходит о пользовании редкими ресурсами, подразделения часто ведут се­бя так, будто они - единственные в организации. В интересах собственно­го выживания, они обязаны бороться за обладание этими ресурсами, так как, в противном случае, окажутся последними в очереди за их использо­вание и рискуют не выполнить тех заданий, которые им поставлены на текущий финансовый год.
  Задача ОУП состоит в том, чтобы помочь подразделениям в этой ситуа­ции добиться общего успеха в завершении выполняемых ими проектов. Для этого им надо уметь измерять и оценивать результаты каждого проекта. Про­цесс такой оценки зачастую реализуется через отчетность о состоянии и ходе выполнения проектов, признанных ключевыми для организации.
  ОУП обязан очень осторожно подходить к выбору представляемых им данных. Когда он только приступает к работе, его первым «проектом» долж­но стать завоевание доверия людей, с которыми ему предстоит совместно ра­ботать. Беспристрастные сообщения и объективные оценки, которые, тем не менее, представляют руководителей проектов в неприглядном свете, способ­ны подорвать такое доверие. Проблема не в том, что ОУП докладывает реальные факты. Он утра­чивает поддержку руководителей подразделений или проектов в тех слущенной системы оценок и на постановку некоторых задач, позволяю­щих продемонстрировать полезность и эффективность ОУП данная ситуация сводит практически на нет все вложенные в дорогостоящую компьютерную программу средства, т.к. данные которыми она начинает «жить» и оперировать из за внутреннего саботажа работников не актуальны.
  Обобщая все вышесказанное хочется отметить что в вопросе выбора системы управления проектами перед ОУП стоит несколько, в том числе и лежащих даже в плоскости корпоративной психологии задач. Нужно так тонко решить задачу, чтобы угодить всем. На самом деле уровень современных технологий по управлению проектами позволяет решать и разрубать казалось бы не решаемые задачи и гордиевы узлы конфликтов, за ресурсы и внимание руководства, ключевым в достижении результативности такого выбора все таки является внимание и поддержка высшего руководства компании, без такого серьезного лобби как показывает практика совершенно бесполезно даже затевать какую либо реструктуризацию.
  Многие организации ищут пути совершенствования контроля выпол­нения проектов. Их руководители постоянно озабочены тем, чтобы проек­ты выполнялись в установленные сроки, тем самым позволяя им дости­гать поставленных квартальных и годовых целей. Все это способствует развитию рынка программных средств управления проектами, которые позволяют организациям оценивать и контролировать состояние выпол­няемых проектов и управлять ими. Большинство организаций стремится к тому, чтобы применять эти средства ко всем проектам, которые они вы­полняют. Такой подход принято называть корпоративным управлением проектами или ЕРМ (Enterprise Project Management).
   
  §3.Организация выбора и внедрения локальной и глобальной коммуникационной сети для оптимизации проектных работ.  
   Достаточное внимание было уделено вопросам технико-экономического обоснования целесообразности создания ОУП в фонде прямых инвестиций Роял Групп, и все же когда  проектный офис решает, кого из поставщиков программных средств управления проектами ему следует выбрать для приобретения у него средств ЕРМ, он должен в первую очередь исходить из того, насколько то или иное средство соответствует задачам ОУП, установленным в технико-экономическом обосновании его создания.
  Перед ОУП в процессе выбора и внедрения программного обеспечения для оптимизации бизнес процессов и использовании локальных и глобальных коммуникационных сетей  встают такие вопросы как:
  • Как можно добиться сокращения продолжительности выполнения проектов;
  • Выбор эффективной коммуникационной стратегии;
  • Как добиться завершения большего числа проектов;
  •  Как фонд может добиться уровня предсказуемости управле­ния тремя основными характеристиками проектов - сроками, бюд­жетами и содержанием (по Демингу[5]).
  ОУП должен содействовать организации в достижении стоящих перед нею целей. Любые другие его работы, не направленные на реше­ние этой основной задачи, являются пустой тратой средств, что рано или поздно становится очевидным. Например, ОУП может потратить недели и месяцы на то, чтобы заставить руководителей проектов и их подчиненных применять те методы, на внедрении которых он настаи­вает. ОУП должен стремиться к тому, чтобы уже в первые три месяца существования наглядно продемонстрировать свою полезность для ор­ганизации, например, содействуя ускоренному завершению проектов. Давление на ОУП с требованиями доказать свою полезность будет на­растать из месяца в месяц, и, в конце концов, наступит момент, когда терпение руководства иссякнет. Деятельность ОУП может быть очень эффективной, если он обеспечивает своевременное представление информации при использовании существующих методов и средств управления проектами. Если ОУП способен помочь руководителю проекта как можно раньше выявить существующие проблемы то для их устранения потребуются корректирующие действия в минимальных дозах. Тем самым, удается понизить напряжение, испытываемое исполнителями проекта и правлением компании. Не следует забывать о том, что  проект, план корректировок которого предусматривает кардинальные изменения, скорее всего будет прикрыт руководством. Кроме того, чем чаще это будет происходить, тем больше у правления компании появляется основание задаваться вопросом, чем занимался ОУП все это время.
  Для установления доверительного к себе отношения ОУП следует прежде всего, указывать на системные недостатки, нежели на ошибки конкретных исполнителей. Он должен помогать руководителям проекта и функциональных подразделений выявлять проблемы и отыскивать пути их решения для доклада правлению компании.
  При отсутствии точной информации о стоимости портфеля проектов, она может быть оценена приближенно. Например, по данным Standish Group и Gartner Group, бюджет одного ИТ-проекта в среднем составляет $500 тыс., а его выполнение занимает порядка 200 календарных дней. Ес­ли организация планирует в новом финансовом году выполнить 100 таких проектов, то в ее бюджете для этого должно быть предусмотрено $50 млн., а суммарная продолжительность выполнения всех этих проектов со­ставит примерно 20 тыс. календарных дней.
  Такая грубая оценка может служить только отправной точкой при оп­ределении надлежащего состава портфеля проектов. Необходимо также знать, какие материальные ценности будут созданы в результате реализа­ции портфеля, если он нацелен на создание необходимых активов, или ка­кие выгоды приобретет организация, если портфель проектов ориентирован на устранение ограничений, препятствующих ее дальнейшему развитию.
  При выборе наиболее подходящих средств ЕРМ должны учитываться многие проблемы, существующие в организации. Общая дилемма, кото­рую приходится решать большинству организаций, состоит в том, следует ли выбрать те средства ЕРМ, которые отвечают требованиям существую­щей инфраструктуры ИТ, или предпочесть им те, что наилучшим образом могут способствовать развитию предприятия. На рынке сейчас предлага­ется столь большое число разнообразных пакетов программных средств ЕРМ, что выбор наиболее эффективного из них может легко перевесить инфраструктурные требования. Вопрос выбора приобретает политическое значение. Организация должна четко ответить на вопрос, собирается ли она применять модель управления проектами, ориентированную на разви­тие рыночных аспектов ее деятельности, или предпочтет воспользоваться преимуществами, которые дают возможность ускоренного развития ее производственных возможностей.
  В поисках ответа на этот вопрос следует рассмотреть  10 ос­новных требований, которым должны отвечать средства ЕРМ.
  1.Простота использования. Индивидуальные представления о просто­те использования того или иного программного средства достаточно субъективны. В любом случае оно должно располагать достаточно сильным аппаратом контекстной поддержки. Для того чтобы оценить простоту того или иного средства, достаточно задать себе вопрос, яв­ляется ли оно столь же простым в применении, как общеизвестный текстовый редактор MS Word.
  2.Внедрение и освоение. Необходимо оценить, как долго займет про­цесс внедрения средства, который включает его освоение конечными пользователями. Если процесс внедрения данного программного средства в управление наиболее важными проектами организации предположительно займет более 90 календарных дней, то это служит серьезным поводом отказаться от него. Такой длительный срок освоения означает, что данное программное средство оказалось чрез мерно сложным, и лучше поискать вместо него какое-либо более простое. Совместимость нового средства с имеющимися в организации программами управления проектами и созданными теми файлами служит серьезным аргументом в его пользу.
  3.Зрелость организации в части управления проектами. Если уровень зрелости работников организации в этой части недостаточно  высок, то, вероятно, следует предпочесть программные средства, отвечающие уровню их подготовленности, поскольку внедрение более сложных средств натолкнется на значительное сопротивление. Если условия работы предприятия требуют применения для управление проектами методики освоенного объема, то выбранное программное средство должно поддерживать эту методику. Поэтому при выборе программного средства необходимо убедиться в том, что в него уже включена соответствующая функция или она может быть добавлена к нему по заказу.
  4.Стоимость обучения. Необходимо определить, способна ли органи­зация собственными силами наладить обучение пользователей или  придется для этого постоянно прибегать к услугам сторонних органи­заций. Следует иметь в виду, что организация, обладающая достаточ­но гибкими возможностями для обучения сотрудников, имеет лучшие перспективы на будущее.
  5.Наличие возможностей для управления портфелями. Любой выби­раемый программный продукт должен обладать возможностями дои объединения данных по многим проектам, и решать задачи их ресурс­ного обеспечения. Данные о ресурсах, обрабатываемые программой, должны включать коды работ, описания квалификации и навыков мно­гочисленных исполнителей и данные о стоимости их использования
  6.Способность к взаимодействию с другими системами. Приобре­таемый пакет программ ЕРМ должен обладать возможностями для простого налаживания его взаимодействия с другими, уже имеющи­мися в организации системами такими, как системы бухгалтерской: учета и управления кадрами. Особенно важна возможность получения из этих систем данных, связанных с учетом рабочего времени.
  7.Сервисные услуги, предоставляемые поставщиком. Перед выборов определенного пакета ЕРМ следует проконсультироваться с другими пользователями, чтобы оценить, достаточен ли для организации уровень сервиса, предоставляемый поставщиком. Своевременная поддержка со стороны поставщика очень важна для организаций, управление проектами в которой сильно зависит от наличия текущей информации. В этом случае гораздо полезнее получить у поставщика полный перечень покупателей его пакета ЕРМ, из которого можно выбрать кандидатуры для посещения и проверки действия пакета на месте.
  8.Финансовое положение поставщика. Необходимо проверить финан­совое положение поставщика. В 2002 г. объем рынка продаж средств ЕРМ составил около $200 млн., а конкуренция между поставщиками этих средств стала еще более ожесточенной. При этом некоторые из них могут испытывать различные финансовые затруднения. Поэтому, после того, как выбрано средство ЕРМ для приобретения, следует так­же решить, стоит ли приобретать исходные коды этого пакета про­грамм на случай, если его поставщик свернет свои операции.
  9.Веб-совместимость. Это требование является абсолютно обязатель­ным, и большинство поставщиков пакетов ЕРМ ему соответствуют. Располагая возможностями получать из любого места доступ к про­ектным данным или просто вводить сведения о времени выполнения проекта, руководителям проектов проще изучать существующие воз­можности и угрозы. Некоторые проекты требуют ежедневного об­новления информации о выполняемых работах, для чего требуются использовать возможности Интернет.
  10. Библиотека документации. Наличие возможности создания и веде­ния подобной библиотеки является еще одним безусловным требова­нием. Большинство пакетов ЕРМ используют для создания базы дан­ных модель «единого репозитория», в котором собрана вся докумен­тация, относящаяся к проекту, право доступа к которой определяется специальными разрешениями. Такая база данных, содержащая всю интеллектуальную собственность, создаваемую в ходе проектных ра­бот, и всю сопроводительную документацию, представляет большую ценность для предприятия. Понятно, что всегда лучше, когда инфор­мация о проекте в любой момент может быть получена по локальной или глобальной сети, нежели когда она рассеяна по портфелям или жестким дискам ПК исполнителей.
  Проанализировав имеющие на рынке EPM системы по описанной выше методике руководством фонда было принято решение о закупке и интеграции в корпоративную систему IТ  EPM Lotus Notes/Domino 5/6.
  3 глава. Описание внедрения и преимуществ программного комплекса по управлению проектами  Lotus Domino §1. Преимущества от использования Lotus Domino для оптимизации проектного управления. Для того чтобы выявить преимущества от использования Lotus Domino как оптимального программного продукта для обеспечения нужд ОУП Роял Групп заглянем в историю. В 60-х гг. появились первые вычислительные сети (ВС) ЭВМ. По сути дела они начали своего рода техническую революцию, сравнимую с появлением первых ЭВМ, так как была предпринята попытка объединить технологию сбора, хранения, передачи и обработки информации на ЭВМ с техникой связи.
  Одной из первых сетей, оказавших влияние на дальнейшее их развитие, явилась сеть АРПА, созданная пятьюдесятью университетами и фирмами США. В настоящее время она охватывает всю территорию США, часть Европы и Азии. Сеть АРПА доказала техническую возможность и экономическую целесообразность разработки больших сетей для более эффективного использования ЭВМ и программного обеспечения.
  В 60-х гг. в Европе сначала были разработаны и внедрены международные сети EIN и Евронет, затем появились национальные сети. В 1972 г. в Вене была внедрена сеть МИПСА, в 1979 г. к ней присоединились 17 стран Европы, СССР, США, Канада, Япония. Она предназначена для проведения фундаментальных работ по проблемам энергетики, продовольствия, сельского хозяйства, здравоохранения и т.д. Кроме того, благодаря новой технологии сеть позволила всем национальным институтам развивать связь друг с другом.
  В 80-х гг. сдана в эксплуатацию система телеобработки статистической информации (СТОСИ), обслуживающая Главный вычислительный центр Центрального статистического управления СССР в Москве и республиканские вычислительные центры в союзных республиках.
  В настоящее время в мире зарегистрировано более 200 глобальных сетей, 54 из которых созданы в США, 16 - в Японии.
  С появлением микроЭВМ и персональных ЭВМ возникли локальные вычислительные сети. Они позволили поднять на качественно новую ступень управление производственным объектом, повысить эффективность использования ЭВМ, улучшить качество обрабатываемой информации, реализовать безбумажную технологию, создать новые технологии. Объединение ЛВС и глобальных сетей открыло доступ к мировым информационным ресурсам.
  Пакет Notes пережил, критику, капризы рынка и взрывоподобный рост Internet, и, не смотря ни на что, развившись в пол­ноценный программный продукт, превзошел все ожидания Lotus Development Corporation. В результате им заинтересовалась фирма IBM — один из гигантов ком­пьютерной промышленности, — которая приобрела Lotus в 1996 году примерно за 1,8 млрд. долларов. Пакет Notes и Domino является чрезвычайно объемным, поэтому довольно трудно обозреть все его возможности, приведем основные которые настроены  и направлены на решение задач управления проектами. Компания Lotus Development Corporation разрабатывала программное обеспечение для ПК, начиная с момента появления Lotus 1-2-3. Программный продукт Lotus Notes появился в 1989 году. В то время он представлял собой распределенную систему уп­равления документами. Серверы Notes (теперь называемые серверами Domino) вы­полнялись только под управлением OS/2, и стоимость инсталляции, рассчитанной на 10 пользователей, не превышала 60 тыс. долларов. К моменту появления версии 3 этого программного продукта, анонсированной в 1994 году, количество пользовате­лей все еще не превышало 1 млн. В 1996 году компания Lotus продала во всем мире почти 10 млн рабочих мест Lotus Notes, практически удвоив количество установлен­ных копий по сравнению с предшествующим годом.
  Стоимость лицензии для одной и той же системы на 10 пользователей стреми­тельно упала. В настоящее время стоимость установки клиента Notes равна пример­но 70 долл. США, a Domino Designer — примерно 400 долл. США. Хотя и политика лицензирования сервера изменилась от ранее принятой линейной структуры и теперь стоимость лицензии для более мощных процессоров обходятся дороже, все же сер­верные лицензии все еще относительно недороги. Аппаратные средства представля­ют собой дополнительную статью расходов, но все равно стоимость аппаратных средств резко упала, в то время как вычислительная мощность стремительно возросла.
  Сегодня Notes и Domino независим от платформы, его серверы и клиенты дос­тупны практически для всех основных операционных систем. Для сервера существу­ют следующие платформы: OS/2, NetWare, Windows 95, Windows NT, UNIX (Solaris, HP-UX и AIX), DEC Alpha, S/390 и AS/400. Для большинства этих операционных систем доступны также клиенты (за исключением NetWare  и кроме того, серверы Domino поддерживают Web-клиенты, а клиенты зависимыми от серверов. Вычислительная мощь серверов Domino значительно выросла.
  Одним из самых больших преимуществ Notes и Domino является возможность пе­редачи информации по локальным вычислительным сетям, WAN, Internet и телефон­ным линиям. Серверы Domino связываются друг с другом при пересылке электрон­ной почты и при синхронизации баз данных. Точно так же пользователь может воспользоваться клиентом Notes для удаленного подключения к серверу Domino в целях получения электронной почты и обмена информацией баз данных с помощью щелчка на единственной кнопке. Процесс обмена информацией в базе данных из­вестен под названием репликация. Никакой другой программный продукт из присут­ствующих ныне на рынке не выполняет репликацию столь быстро и хорошо, как это делает Lotus Notes и Domino.
  Два года назад многие предсказывали грядущий закат эры Notes из-за широкого распространения Internet и intranet-сетей. К счастью, эти мрачные прогнозы оказа­лись несостоятельными. На сегодняшний день степень интеграции Notes с Internet является большей, чем у любого другого программного продукта. В середине 1996 года компания Lotus анонсировала первый в мире сервер приложений I-Net (сервер Domino) нашедший широкое применение в промышленности. Термин I-Net имеет отношение к intranet-сети, поддерживающей HTML-содержимое над HTTP, или к Internet. Развитие новой индустрии сосредоточивается на поддержке приложений для заказчиков в Web, использующих новую технологию. В версии 4 наряду с Domino Web Server фирма Lotus также представила технологию, позволяющую отсылать и при­нимать почту Internet с помощью почтовых ящиков Notes: SMTP MTA, или Simple Message Transfer Protocol Message Transfer Agent (Агент передачи сообщений с по­мощью простого протокола передачи сообщений). В версии 5 Domino маршрутизатор почты Domino может работать как с почтой Notes, так и с почтой SMTP. В допол­нение к этому было разработано целое семейство программных продуктов, основан­ных на Internet, включая Domino.Merchant, Domino.Broadcast и eSuite.
  Вокруг Notes сформировалось весьма разностороннее и яркое сообщество. Это со­общество состоит из разработчиков приложений, системных администраторов, кон­сультационных компаний. Ими используется широкий спектр инструментальных средств от сторонних производителей и вспомогательного программного обеспечения. Сюда также включается сообщество Lotus Business Partner, насчитывающее более 18 тыс. членов. Компания Lotus разработала программу Business Partner и программу сер­тификации для консультантов, разработчиков и администраторов. 
  Сердцем информационной эры или информационной революции являются зна­ния. Жизнеспособность бизнеса определяется возможностью использования, управ­ления и разделения информации.  До появления сетевых приложений совмест­ное использование информации было возможно только с помощью физических но­сителей файлов, передаваемых от одного пользователя к другому (этот способ так­же известен под названием sneaker net (снующая сеть)). Можно было также печатать отчеты и использовать их совместно с другими пользователями. Во многих отноше­ниях информация носила частный и автономный характер; она становилась достоя­нием общественности только после того, как была напечатана и распределена. За­частую лица, ответственные за сбор и распространение знаний, должны были ревниво заботиться о сохранности такой информации. С другой стороны, групповое программное обеспечение использует сети для пе­редачи информации среди отдельных лиц и организаций. Групповое программное обеспечение поддерживает работу в группах. Оно хорошо соответствует нынешнему деловому климату. Групповое программное обеспечение развивается, исходя из двух базовых мо­делей: модели share (совместного использования) и модели send (пересылка).
  Прикладные программы, которые работают в сетевой среде, дают возможность пользователям совместно использовать данные. Примерами могут служить приклад­ные программы, написанные с применением большого разнообразия языков и ме­ханизмов баз данных типа С, dBASE, FoxPro, Sybase, Oracle и PowerBuilder. Частично новейшие текстовые процессоры и программное обеспечение поддержки электрон­ных таблиц типа Lotus WordPro, Lotus 1-2-3 и Microsoft Word дают возможность груп­пам пользователей сотрудничать при работе над отдельным документом или элект­ронной таблицей. Автор документа может блокировать последующих редакторов, вносящих изменения определенного вида в некоторые области документов, и может поддерживать управление версиями.
  Модель совместного использования полагается на то, что документ или прило­жение базы данных находится в области, доступной для всех пользователей, т.е. со­вместно используются.
  Возможно, в ответ на успех Notes и Domino свойства, которые используются при групповой обработке данных, были добавлены в текстовые процессоры типа Microsoft Word и даже в приложения электронных таблиц. Свойства, которые играют важную роль при совместном использовании, типа поддержки главных документов и управ­ления версиями, были добавлены к имеющейся программе, а ранее они существо­вали автономно. С другой стороны, Notes и Domino были разработаны таким обра­зом, чтобы позволить группам людей сотрудничать между собой.
  Одно из ключевых свойств базы данных Domino заключается в том, что пользователь может распределять копии этой базы данных для клиентов Notes (не являющихся Web-клиентами) и других серверов. С помощью процесса, называемого репликацией, клиенты и серверы Notes поддерживают синхронизацию информации.
  Подытоживая сказанное, можно отметить, что Notes является испытанным и мощ­ным программным продуктом. Никакая другая программа не может обеспечить того, что предлагает Notes и Domino. Даже те программные продукты, которые прибли­жаются по своим возможностям к Notes, должны пройти длительный путь развития, чтобы составить достойную конкуренцию. Поэтому данная программа полностью удовлетворяет запросам фонда прямых инвестиций «Роял Групп» и является мощным помощником и коммуникатором ОСУП, в части управления коммуникациями и оптимизации использования глобальных и локальных сетей.
  §2. Описание архитектуры и логики построения офиса управления проектами на основе Lotus Domino    
  Основные важные для ОУП возможности системы:
  • Использование Project Notebook
  • Обзор жизненного цикла разработки ПО
  • Стадия проектирования
  • Стадия управления проектов
  • Тестирование и обучение
  • Оценка успеха проекта
  Можно получить конечный продукт при использовании современного, развивающегося и инкрементного подхода к раз­работке программного обеспечения.
  Представим себе достаточно большой проект, итеративная разработка которого приводит к изменениям, которые почти всегда кажутся слишком разрушительными. Разработка только одной части (или модуля) проекта может привести к невозмож­ности полного тестирования системы. Если вдруг обнаруживаются ошибки при раз­работке и интегрировании одной из "последних" подсистем в общую систему, то очень трудно провести корректирующие изменения в системе к назначенному сроку.
  Решение проблемы заключается в том, чтобы проект проходил следующие ста­дии на каждом этапе разработки. Первое приложение этих действий направлено на то, чтобы помочь определить четкий набор требований, построенных на базе перс­пектив моделей, каких-либо прототипов  и результатов обсуждений с клиентом. Эти требования могут принять форму простого списка свойств или развернутого спис­ка вариантов использования методов. Когда проект переходит в стадию полномасш­табной разработки (стадия построения), вновь могут применяться действия по раз­работке, только на этот раз более углубленно. В дополнение к этому, если клиент выдвигает новые требования, снова необходимо предпринять действия, удовлетво­ряющие этим новым условиям. Все эти требования Notes позволяет безболезненно и дружелюбно для пользователя учитывать и настраивать. Хочется отметить что Notes имеет очень дружественный и понятный в использовании интерфес.
  Один из наиболее важных аспектов любого нетривиального проекта — это спо­собность передавать части проекта другим разработчикам. Лучший способ, позволя­ющий добиться этого в интегрированной среде разработки, — использовать логичес­кий Project Notebook (Блокнот проекта), который будет содержаться в центральном месте нахождения проекта. Это позволит всем разработчикам получить доступ к Notebook. Обычно определенные разделы Notebook создает и обновляет более одно­го человека, а часто целая команда. Блокнот Notebook — это место для хранения продуктов разработки программного обеспечения во время эволюции проекта.
  Важно то, что работа с Project Notebook происходит в активной манере. Блокнот Notebook не стоит многого, если он не обновляется последними указаниями, изме­нениями в требованиях, алгоритмическими и поведенческими записями и согласо­ванными изменениями в графике. Поддерживая такой Notebook, становится гораздо легче подключать к работе над проектом новых людей. Ими могут быть новые раз­работчики, новые заказчики, новые представители менеджмента, маркетинга и т.д. Значение Notebook для работников  организации, работающей в едином порыве над реализацией проектов, трудно переоценить.
  В зависимости от среды этот логический блокнот может принимать различные формы. Во многих средах разработки, базирующихся на файлах, используются инструментальные средства сторонних производителей для работы с исходным кодом и другими документами проекта. Интегрированные командные среды разработки, такие как StarTeam фирмы StarBase  дают пользователям полный доступ к хранилищу Notebook (даже с удаленного местоположения или через Internet).
  Можно также установить Project Notebook при работе в Notes. Можно начать с шаблонов Document Library (Библиотека документов), и расширить их с учетом своих требований, можно расширить поля базы данных документа задан­ные по умолчанию, чтобы включить дополнительную информацию: Owner (Владелец) — это может быть раскрывающийся список имен пользователей, несущих ответственность за контроль документа до самого окончания работы над ним. Например, документ Test Scenario (Тестовый сценарий) вполне может быть создан многочисленными тестерами; однако только главный тестер может иметь полную собственность над документом, чтобы видеть, что он закончен и обнов­ляется при необходимости.Status (Статус) — в дополнение к возможности просмотра цикла поле статуса документа может показывать различные уровни состояния документа. Например, статус документа может изменяться от Not Started (He начат) до Draft (Плани­руется), In Review (Просматривается), Accepted (Принят) или Superseded (Заменен).Traceability (Отслеживаемостъ) — во многих случаях изменение одного докумен­та требует обновления других. Это многозначное поле позволяет разработчику до­кумента указать любое количество других документов, которые нужно проверять на необходимость внесения изменений. Это значит, что команда разработчиков имеет возможность для более простого проведения анализа на общем уровне до­кументов. Отсюда (и в соединении с четкими требованиями инструмента анали­за) можно получить более подробную информацию последовательного анализа.Comments (Комментарии) — по мере того как пользователи изменяют документ, они могут записывать информацию в файл, зависящий от этих изменений.
   
  Использование инструмента управления требованиями может стать очень значи­мым, особенно для больших проектов. Объединив требования, в которые перепле­тены с содержанием документа требований, в список становится гораздо легче про­сматривать следующую информацию:
  •   Что нужно сделать (в форме списка)
  •   Относительное старшинство требований
  •   Отслеживание требований
  •   Возможность проводить изучение и анализ зависимостей
  Используя инструментальное средство (такое, как Requisite Pro, DOORS, простой инструмент создания схем, текстовый процессор или даже электронную таблицу) для получения отдельных требований, менеджер проекта всегда может получить момен­тальный список текущих требований. Подобный инструмент от сторонних произво­дителей также делает возможной поддержку дополнительной информации о каждом требовании, касающуюся, например, статуса, приоритета, приблизи­тельного объема работ и ответственного лица.
  Project Notebook представляет множество преимуществ для пользователя. Четко сфор­мулировав требования, проект можно сделать более конкретным, чем просто умоз­рительная идея. Используя поэтапный подход к администрированию документации и описания жизненного цикла проекта, Project Notebook, перво­начальные определения требований (Requirements Definition) и стадию разработки (с первоначальным проектом и созданием прототипов), заказчик или инвестор и пользователь он же руководитель проекта  получат в свои руки руководство к действию.
  При четком документировании, согласованном обеими сторонами (командой раз­работчиков и клиентом) проект имеет немало шансов на успех. Это особенно чувствуется при сравнении с проектом, который имеет плохие или краткие документы требований и заказчик которого постоянно пересматривает требования. Команда раз­работчиков, кажется, никогда не имеет возможности поймать и выполнить что-либо это симптомы синдрома "убегающей мишени".
  На начальном этапе прилагаются усилия к тому, чтобы в результате проведения заседаний организаторов совместного дела решить следующие вопросы:
  • Разработать уточненный список требований, показывающих, какой именно продукт будет создан, очертить диапазон его применения, концепцию операций, критическую оценку успеха и т.д.
  • Создать список высокоуровневых вариантов использования, подчеркивающих архитектуру и определяющих важные компромиссы в проекте.
  • Приблизительно оценить стоимость и график работы в рамках проекта, на стадии проектирования.
  • Рассмотреть опасность потенциального риска.
  Этап тщательной разработки (Elaboration Phate) — это как раз то время, когда разработчики максимально учитывают все требования, продумывают вопросы, связанные с архитектурой, проектом, прототипами и другими факторами. Конечная цель этапа тщательной разработки — получить достаточно информации, чтобы назвать фиксированную цену (стоимость, график и ресурсные требования) и запустить проект в стадию производства (или, по крайней мере, если не определить фиксированную цену, то приблизиться к этапу, на котором может быть сделан приблизительный расчет с некоторым согласованным допуском, например, в 20%).
  В течение этапа тщательной разработки входные данные для определения требования поступают в различных формах, размерах и форматах. Ниже представлены при меры типов входных данных для требований:
  • Существующие бизнес-процедуры
  • Формы
  • Формальная постановка задачи
  • Документы требований
  • Используемые системы (возможно, одна из которых должна быть заменена)
  • Встречи с маркетологами и экспертами в данной области
  Для уточнения требований нужно сделать больше чем просто определить их. Когда руководитель проекта управляет командами разработчиков или разрабатывает свои собственные проекты, каждый,  как правило,  отдельно разрабатывает списки требований, применяет метод объек­тного моделирования и обычно в некоторой форме создает прототипы. Конечным ре­зультатом этих конкурирующих итеративных упражнений является набор документирован­ных требований.
  
  Рис. 4  Установка границ проекта
  Во время сбора требований и разработки первоначального проекта может посту­пить информация, которая необходима и важна для проекта, однако выходит за пре­делы требований. Часто мы оставляем эти находки в проектной документации (т.е. добавляем их в список свойств) и объектных моделях, но помечаем их "Не в этот раз". Как отмечает Питер Коуд (Obect-Oriented Analysis), это позволяет отразить и со­хранить подобные открытия на том этапе, когда они возникают природным обра­зом. Однако не нужно позволить проекту "завязнуть" в лишней несогласованной (по крайней мере, для этой версии приложения) работе.
  Поиск новых свойств, или, иначе, просачивание свойств, — это просто добавле­ние новых идей, которые находятся за текущими границами проекта.
  Notes является достаточ­но гибким для внесения изменений "по дороге". Однако не нужно претворять в жизнь каждое мелкое новое свойство, найденное разработчиками или клиентом, иначе это приведет к риску для контрактных обязательств (срыв графика работы и повышение цены продукта). Кроме того, с новыми потенциальными свойствами нужно обходиться так же, как и с любыми другими потенциальными требованиями: клиент и команда раз­работчиков должны работать вместе, прибегая к таким же действиям, как и при ра­боте с полным приложением.
  Один из способов, позволяющий избежать негативных аспектов просачивания свойств, — это сконцентрироваться на вариантах использования высшего приоритета и свойствах, которые имеют наибольшее значение для клиента. Если позволят ре­сурсы, то можно переключить свое внимание на элементы низкого приоритета и даже начать рассматривать те свойства, которые изначально находились за пределами про­екта. Это может быть легко выполнено, если требования поддерживаются в виде пе­речня приоритетных условий.
  С таким списком свойств можно браться за неучтенные прежде свойства на бо­лее твердой основе. Поэтапно, используя такой инструмент, как библиотеку Project,в один из ее инструментариев входит построение сетевого графика и диаграммы Ганта, или даже  можно более простую электронную таблицу, можно распределить свойства так, чтобы каждое из них требовало не более двух недель рабочего времени (даже если это и означает разбиение свойства на отдельные задачи). Это может повлечь за собой создание под-свойств и подзадач, однако существует множество преимуществ при использовании малых задач, включая следующие:
  • Большая надежность приблизительных прогнозов
  • Лучшая возможность отслеживания процесса разработки
  • Появление ощущения завершенности для разработчиков, когда работа над свой­ством закончена
  • Более гибкое распределение ресурсов
  • Общее повышение предсказуемости дат выхода новых версий с определенным уровнем функциональных свойств
  В Project Notebook можно заменить спецификацию типичных функциональных требований (Functional Requirements) на перечень всех вариантов использования. Включение и функциональных спецификаций, и мо­дели вариантов использования будет чрезмерным, кроме того, потребуется их син­хронизация. Такой инструмент, как Together, является экспертом в создании ком­бинированной текстовой и графической документации для требований, базирующихся на вариантах использования.
  Важность модели вариантов использования заключается в том, что она может слу­жить для поддержки всего процесса разработки приложения, начиная от анализа и переходя к дальнейшим этапам. Должна быть возможность отследить все действия разработчиков в обратном направлении для одного или более вариантов использо­вания. Один из методов выполнения этого состоит в том, чтобы варианты исполь­зования помогали выполнять последующие задачи, возможно, при этом выявляют­ся свойства и разрабатываются последовательные диаграммы.
  Из-за большого размера некоторых проектов часто необходимо разделить проблем­ную область приложения на вертикальные части, представляющие области объектов. Например, на производстве объектные области могут включать в себя следующее:
  • Продукт (части, которые производятся, и расходуемые части);
  • Перечень материалов (список частей для производимого продукта);
  • Производственная база (определение производственных площадей и ресурсов);
  • План процесса (этапы по изготовлению продукта);
  • Утверждение (прохождение этапов по плану процесса и утверждение изготовлен­ных частей);
  Большинство вертикальных разделений могут быть относительно независимыми, что позволяет разработчикам работать в специализированных областях. Там, где об­ласти взаимодействуют, необходимо создать ограничения или интерфейсы. Утверж­дение (работа на производственных площадях выполнена), например, неизбежно связано почти со всеми остальными областями.
  Notes располагает простыми методами для определения базы данных. Если есть и другие потребности в постоянном хранилище, то нужно создавать отдельные классы, поддерживающие непосредственно требуемые функциональные. Это позво­лит поддерживать данные, относящиеся к постоянному хранилищу, "чистыми" в том смысле, что они не будут "загрязнены" каким-либо конкретным механизмом.
  Уровень  интеграции с внешней средой содержит объекты, поддерживающие интерфейс со внешними систе­мами или устройствами. Здесь встроены такие объекты, как низкоуровневые прото­колы, которые оставляют объекты данных "чистыми" от деталей, специфичных для реа­лизации. Другие примеры могут включать создание объектов-заместителей, служащих в качестве оболочки для наследственных систем или других внешних компьютеров. Это также и место, где будут создаваться классы, реализующее поведение физичес­ких устройств (например, сенсоров, устройств считывания с карт, сканирующих систем безопасности или электронных систем перевода денег).
  На этапе проектирования в Project Notebook необходимо добавить следующие до­кументы:
  •  Описание проблемы — этот документ описывает высокоуровневые потребности клиента четким и простым языком.
  •   Варианты использования — список действующих лиц, участвующих в приложении, и список четко определенных функциональных требований, описывающих, как бу­дет использоваться система. Они должны быть разделены на компоненты полных свойств, наборы свойств, свойства и т.д.
  •   Нефункциональные требования — сюда входят такие периферийные требования, как ограничения по времени, прогнозируемое использование клиентом (количество различных пользователей, общее число пользователей, темпы осуществления тран­закций и т.д.), требуемые интерфейсы для внешних систем и конечные среды (ап­паратное обеспечение и операционные системы).
  • Тестовый план одобрения — этот план очерчивает тестовый план (и ожидаемые ре­зультаты), который подтвердит, что приложение соответствует установленным целям.
  • Методы и инструменты разработки — определяет процессы, стандарты, инстру­менты менеджмента проекта, методы проверки качества, инструменты разработ­ки, инструменты тестирования и т.д.
  • Проектный план — содержит график выполнения задач (базирующихся на доку­менте требований) и список требуемых ресурсов (и, возможно, план их приме­нения)
  • План обеспечения гарантии качества — описывает, как будет проводиться отсле­живание и устранение ошибок, а также, возможно, и процедуры по постоянно­му улучшению продукта, методы проверки программного кода и т.д.
  • Тестовый план — документирует метод, который будет применен для проверки того, что приложение отвечает спецификациям (и функциональным, и нефунк­циональным)
  • Оценка проекта — указывает, как и по какой шкале будет производиться оценка прогресса и качества
  В зависимости от размеров проекта может существовать один или несколько фи­зических документов, входящих в состав Project Notebook, а некоторые детали мо­гут быть опущены. Важным здесь является не как информация документирована, а то, что вовлечено в процесс, а также тот простой факт, что информация докумен­тирована.
  Эти документы будут добавлены в Project Notebook и будут поддерживаться по мере разработки приложения.
  По мере записи и отслеживания выполнения свойств можно одновременно оце­нить временную производительность. Если хорошо выполнена работа по разбиению процесса разработки на определенные свойства и наборы свойств, а также работа по проверке скорости выполнения свойств, то это может служить твердой основой для приблизительной оценки и точного выполнения по времени. С другой стороны, если разработка каждого свойства заняла больше времени или были пропущены многие подсвойства, необходимые для реализации какого-либо свойства, нужно соответству­ющим образом изменить и сами процессы.
  Обобщая все вышесказанное хочется еще раз отметить достоинства системы корпоративного управления данными Lotus Notes  Domino в применении для управления проектами в фонде. Систем отличается оптимальным соотношением цена и качество. Неоспоримым достоинстов является повышенная безопасность хранения и передачи данных, быстрота и легкость настройки которая доступна простому пользователю, в компании на основе Notes реализовано не только хранение и обработка данных по инвестиционным пакетам, подготовка еженедельных отчетов для высшего руководства, а также существует внутренний развлекательно информационный он-лайн портал «Газета» на «страницах» данного портала все участники внутренней корпоративной сети имеют возможность оперативно узнавать данные об реализации стратегических целей компании а также имеют возможность обсудить не покидая рабочего места рабочие моменты, поздравить коллегу с днем рождения, да и порой просто высказаться на какую-нибудь интересную тему.
  Фонд внимательно следит за новшествами и новыми линейками продукции IBM и регулярно обновляет Lotus Notes, также проводит обучение своих сотрудников, и думается, что такое плодотворное сотрудничество будет продолжаться.
   
   
  Заключение. Выводы, дальнейшие перспективы развития проектного управления в России. Заключение  
  В дипломной работе было представлено внедрение программного комплекса Lotus Domino в корпоративную систему управления проектами в фонде прямых инвестиций «Роял Групп», а также рассмотрены результаты его использования  для оптимизации проектных работ.
    Результатом внедрения  является:
  ·   Уменьшение количества переменных затрат.
  ·   Централизованный отчет о деятельности подразделений фонда, данный аспект наиболее важен с точки зрения возникавших коммуникационных конфликтов, и устранения «непрозрачной и неактуальной» отчетности.
  ·   Уменьшение времени и ресурсов для оформления  и ведения проектной документации.
  ·   Возникла корпоративная культура коммуникации по локальной сети, что позволило значительно снизить расходы  фонда на телефонную связь. Данное снижение является приятным следствием оптимизации взаимодействия между участниками  проектных групп.
  ·   Увеличение общего числа выполняемых проектов.
  ·   Увеличение мотивационной части вознаграждения сотрудников
  ·   Повышение капитализации фонда
  Также следует отметить что, средства  и методы управление развиваются и не стоят на месте, поэтому вряд ли будет найдено универсальное средство, которое позволит полностью оптимизировать процесс управления проектами. Т.к. зачастую качественное функционирование офиса управления проектами, зависит вовсе не от выбранного программного продукта, а от административного аппарата  и от решения на уровне владельца бизнеса внедрять ли новую культуру коммуникации.
  В данной работе рассмотрено использование программного комплекса Lotus Domino как объединяющего  локальные  и  глобальные коммуникационные сети при оптимизации проектных работ
  Внедрение данной системы было экономически выгодно для фонда, так как аналоги (несмотря на их небольшую цену), нуждаются в доработке и адаптации к деятельности фонда, которая зачастую может выполняться только разработчиками программы, что стоит гораздо дороже и повлечет за собой значительное увеличение переменных затрат. Вследствие  чего, увеличится стоимость реализуемых фондов проектов  и уменьшится число заказчиков, что совершенно недопустимо при нынешней рыночной ситуации, когда количество игроков на рынке увеличивается день ото дня и конкурентная борьба обостряется. Сегодня в Россию пришел рынок, что повлекло за собой соблюдение правил новой игры. Современные компании конкурируют не только качеством и ассортиментов предлагаемых ими услуг но и новой коммуникативной культурой обслуживая,  и в первую очередь идет борьба за высокие технологии.
  Выводы, дальнейшие перспективы развития проектного управления в России. Как уже отмечалось, что на сегодняшний день в России сложилась ситуация при которой сотни компаний активно осваивают и внедряют стандарты проектного управления, разрабатывают и апробируют методологии управления проектами. Успешная проектная деятельность становится одним из важнейших конкурентных преимуществ предприятий и требует поддержки через хорошо отлаженные информационные системы. Спрос на «проектную» функциональность побуждает даже «неспециализированных» разработчиков внедрять в свои системы модули, минимально отражающие специфику проектной деятельности и частично автоматизирующие ее. Конечно, уровень компетенций в области управления проектами «случайных» поставщиков невысок и не может рассматриваться всерьез. Активная конкуренция развивается между крупными игроками. Мировые разработчики борются за лидерство на рынке, закладывая в собственные системы дополнительный функционал, новые математические модели анализа и прогнозирования развития проектов, их влияния на рост компании, расширяют плоскости и разрезы аналитики. Основная борьба на этом поприще разворачивается между наиболее крупными системами, ориентированными на различные масштабы управления — от стратегического уровня — портфели проектов — до оперативного — управление проектами. Сегодня тенденции на российском рынке соответствуют мировым. Проектное управление становится решающим фактором успеха крупнейших компаний в условиях планирования и моделирования дальнейшего развития бизнеса вплоть до нескольких десятков лет вперед. Аналитические отчеты Gartner и Forrester за 2006 год ясно показали, что на рынке появляются новые мировые лидеры — компании, наиболее четко и ясно понимающие будущность и ключевые векторы развития систем управления портфелями проектов.
  Подавляющее большинство руководителей проектов и проектных команд руководствуется в своей работы стандартом ANSI PMI PMBOK. Сегодня он признан общемировым. Десятками тысяч компаний используется сегодня версия стандарта ANSI PMI PMBOK Guide 2004, выпущенная, соответственно, в 2004 году. Стандарт обновляется раз в 4 года, и в 2008 году должен выйти его обновленный вариант — ANSI PMI PMBOK Guide 2008. Предпечатные версии нового свода знаний по управлению проектами уже обсуждаются в профессиональных кругах в режиме «обкатки».
  Но тем не менее идея разработки в России национального стандарта по управлению проектами витает в воздухе. Западные практики не всегда отвечают отечественным реалиям и нередко содержат непрогнозируемые «подводные камни», определяющие бесперспективность проекта именно в России, еще на этапе его запуска. Внесение типично «отечественных» корректив в опыт, накопленный и структурированный мировым сообществом, могло бы обеспечить России свод знаний и правил, значительно повышающих эффективность проектной деятельности. В частности, стандарт мог бы дать мощную базу для более эффективной реализации в России широко обсуждаемых национальных проектов.
  В целом уровень зрелости российских компаний в области проектного управления существенно вырос Рынок пришел к осознанию, что при построении системы управления проектами компания в первую очередь должна выполнить сложный организационный проект, перестраивающий распределение полномочий и ответственности за инновации на предприятии, российский рынок готов предложить для этого высококвалифицированных специалистов с масштабным опытом участия в проектах и профессиональной сертификацией. Но на сегодняшний день и скорее всего эта тенденция сохранится в ближайшем обозримом будущем на рынке действует ограниченное число компаний, обладающих широкими и подтвержденными компетенциями в области проектного менеджмента. Их привлечение в качестве подрядчиков по крупным и значимым проектам позволяет заказчикам, специализирующимся в своих областях, далеких от проектного управления, не тратить времени на поиск квалифицированных специалистов, обеспечивает проектам гарантии успешного выполнения. Благодаря этому пониманию в России постепенно начинает развиваться практика передачи сложных и важных проектов на аутсорсинг специализированным компаниям, давно уже устоявшаяся на Западе.
  Эффективная реализация проектов требует от компаний единого понимания проектными командами принципов проектного управления, общей терминологии и одинакового видения хода развития проекта, владения теоретическими и практическими навыками управления. Компаниями, получившими необходимый базис знаний в области управления проектами, часто востребованы консалтинговые услуги — аудит разработанных проектных подходов, оценка уровня проектной зрелости компании, корректировка методологии управления проектами или доработка/создание корпоративной системы управления проектами. Сейчас значительно растет спрос на услугу управления проектами, профессиональное управление уникальными проектами, портфелями и программами. В свете активного развития рынка управления проектами эта тенденция будет сохраняться.
   
   
  Список использованной литературы  
  1.   Линд Дебби Lotus Notes  и Domino 5\6 Энциклопедия программиста/ Дебби Линд, Стив Керн: 2-е изд., перераб. И доп.;Пер. с англ. –К.: ООО « ТИД « ДС»,2005. -1024 с.
  2.   Александр Кутузов: Идея разработки в России национального стандарта по управлению проектами витает в воздухе/На вопросы CNews отвечает Александр Кутузов, управляющий партнер компании PM Expert.  http://www.cnews.ru/reviews/free/2006/int/pmexpert/
   
  3.   Майкл В. Ньюэлл. Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2006.
   
  4.   К. Хелдман. Профессиональное управление проектом. Пер. с англ. – М.: Бином. Лаборатория знаний, 2005.
   
  5.   Управление инвестиционно-строительными проектами: международный подход. Руководство/Под ред. И.И. Мазура, В.Д. Шапиро. – М.: Авваллон, 2004.
   
  6.   Товб А. С., Ципес Г. Л. Управление проектами. Стандарты, методы, опыт.– М.: «Олимп-Бизнес», 2005.
   
  7.   Основы инновационного менеджмента. Теория и практика. Учебник/Под ред. А.К. Казанцева и Л.Э. Миндели. – «Экономика», 2004.
   
  8.   Арчибальд Р. Управление высокотехнологичными программами и проектами: Пер. с англ. - М.: ДМК Пресс, 2002. - 464 с.: ил.
  9.   Project Management Body of Knowledge, Project Management Institute, USA.
   
  10. Управление проектами/ Клиффорд Ф. Грей, Эрик У. Ларсон. Практическое руководство, Пер. с англ. М.: Дело и сервис, 2003
   
  11. Елиферов В.Г., Репин В.В. Бизнес-процессы: Регламентация и управление: Учебник. – М.:ИНФРА-М, 2005. – 319 с.
   
  12. Забродин Ю.Н., Коликов В.Л., Саруханов А.М. Управление нефтегазостроительными проектами. – М.: Экономика, 2004.
  13. Локк Д. Основы управления проектами / Пер. с англ.-  М.:  «НИРРО», 2004.
   
  14. Управление проектами. Толковый англо-русский словарь-справочник. Под ред. В.Д. Шапиро. М.:Высшая школа, 2000.
  15. Риск-анализ инвестиционного проекта: Учебник для вузов/Под ред. М.В.Грачевой. - М.:ЮНИТИ-ДАНА, 2001.-351 с
   
  16. Волков А.С., Марченко А.А.. Оценка  эффективности инвестиционных проектов: Учеб. Пособие. –М.: Издательство РИОР, 2006.-111с.
   
  17. www.ccg-usa.com (Communication Consulting Group)
   
  18.  Бахарев А.Р., Коммуникации внутри компании: как добиться их эффективности.: www. pmexpert.ru
   
  19. Грушевицкая Т.Г., Попков В.Д., Садохин А.П. Основы межкультурной коммуникации: Учебник для вузов (Под ред. А.П. Садохина. - М.:ЮНИТИ-ДАНА, 2002. - 352с
   
   
  Приложения
   
   
  Положение о Проектном центрекомпании ЗАО «РОЯЛ ГРУПП»
   
   
   Москва
  2006 г.
   
  1. Общие положения
  1.1. Проектный центр ЗАО «РОЯЛ  ГРУПП» (далее Проектный центр) является самостоятельным структурным подразделением компании ЗАО «РОЭЛ Проекты и Финансы» (далее Компании).
  1.2. Проектный центр создается и ликвидируется приказом Генерального директора Компании.
  1.3. В своей деятельности Проектный центр руководствуется: Уставом Компании, приказами и распоряжениями Генерального директора, настоящим Положением, Стандартом по управлению проектами и другими корпоративными стандартами Компании.
   
  2. Цели и Задачи Проектного Центра
  Основными целями Проектного центра являются:
  2.1.  Повышение качества исполнения проектов, в части соответствия целям, соблюдения сроков и бюджетов;
  2.2.  Повышения производительности Компании в части исполнения проектов, в том числе за счет планирования, календарного планирования, бюджетирования;
  2.3.  Обеспечение «прозрачности» исполнения проектов путем документирования всех бизнес-процессов, введения стандартной регулярной отчетности, организации хранения информации по проектам.
  2.4.  Формирование Базы знаний Компании.
   
   
  Основными задачами являются:
  2.5.  Внедрение и поддержка единого стандарта управления проектами  Компании, в том числе
  2.5.1.   Внедрение стандартной практики запуска, планирования, исполнения и завершения проектов.
  2.5.2.   Внедрение единой системы информирования заинтересованных сторон о ходе работы над проектами.
   
  2.6. Помощь руководителям проектов на всех этапах реализации проектов.
  2.7. Осуществление процедур мониторинга и контроля планирования и исполнения в целях оптимизации работ по проектам.
  2.8. Формирование и сопровождение архивной базы завершенных проектов
  2.9. Формирование и сопровождение базы знаний по реализации проектов
  2.10. Организация обучения менеджеров проектов Стандарту и регламентам проектного управления, принятым в Компании.
   
  3. Организационная структура Проектного центра
  3.1. Организационная структура и штатная численность Проектного центра утверждается Генеральным директором Компании.
  3.2. Проектный центр возглавляется Директором, назначаемым на должность приказом Генерального Директора.
  3.3. Проектный центр подчиняется непосредственно Исполнительному директору компании.
  3.4. Проектный центр имеет в своем составе следующие группы:
  3.4.1.   Группу администрирования проектов
  3.4.2.   Группу методической поддержки
  3.4.3.   Группу аналитики
  3.4.4.   Специалиста по IT
  3.5.  Группы внутри Проектного Центра не являются самостоятельными структурными подразделениями, а выделены по областям компетенции в соответствии с задачами и функциями, выполняемыми работниками.
  3.6. Проектный центр, в случае обоснованной необходимости, привлекает специалистов по распоряжению Генерального директора и по представлению Директора проектного центра для выполнения работ в рамках проектов.
   
  4. Функции
   
  4.1.  В области администрирования проектов
  4.1.1.   Ведение реестра проектов.
  4.1.2.   Проверка соответствия подготовки проектных документов Стандарту управления проектами, в том числе входной контроль наличия пакета проектных документов в соответствии со Стандартом управления проектами.
  -   Паспорт проекта, включая Перечень рисков и План коммуникаций
  -   Календарный план проекта
  -   Бюджет проекта
  -   Соглашение с Заказчиком по реализации проекта
  4.1.3.   Контроль соответствия хода исполнения  планам проектов, в том числе контроль исполнения графиков проектов, бюджетов проектов.
  4.1.4.   Контроль и координация изменений планов исполнения проектов.
  4.1.5.   Подготовка отчетов о ходе выполнения проектов для всех заинтересованных лиц в соответствии с Планом коммуникаций.
   
  4.2. В области методической поддержки и документооборота.
  4.2.1.   Методическая помощь в подготовке пакета проектных документов, в т.ч. разработка регламентов/инструкций для руководителей проектов.
  4.2.2.   Создание Базы Знаний для использования в будущих проектах.
  4.2.3.   Архивирование завершенных и закрытых проектов
  4.2.4.   Поддержка руководителей проектов в процессе реализации проектов.
   
  4.3. В области аналитики
  4.3.1.   Предпроектная проработка, в том числе:
  -   Комплексный анализ бизнес-идеи на предмет ее реализуемости, экономической эффективности и рисков в соответствии с Регламентом о предпроектной проработке и выборе проектов для реализации.
   
  4.3.2.   Подготовка  справочных и аналитических материалов, для проектов на всех стадиях, в т.ч.:
  -   по оценке внутриполитической и социально-экономической, криминогенной и иной ситуации, бизнес-элитам и группам влияния.
  -   отраслевых и тематических аналитических справок по рынкам товаров и услуг, состоянию отраслей (подотраслей) экономики России и стран СНГ;
  -   подготовка объемных блоков информации по субъектам Федерации (структура местной законодательной, исполнительной, судебной, представительной власти, представительства центральных органов власти в субъекте. Набор биографий и характеристик. Расстановка политических сил. Состояние экономики, характеристика базовых и градообразующих предприятий).
  -   проверка дееспособности физических и юридических лиц, их отношения к криминалу, причастности к незаконной деятельности, судимости, наличия собственности и т.д.
  -   Подготовка графических схем взаимоотношений и связей юридических и физических лиц по линии личных, деловых, родственных и иных связей.
  -   установление взаимосвязей на линиях проработки физических и юридических лиц, определение путей  подходов, основных и вспомогательных каналов установления с ними взаимоотношений или оказания влияния через третьих лиц;
  4.4. В области IT
  4.4.1.   Установка и отладка инструментов по управлению проектами.
  4.4.2.   Обучение участников проектной деятельности работе с инструментами.
   
  4.5 .В области взаимодействия с Региональными представительствами.
    4.5.1. Ведение совместно с  Региональными представительствами единого реестра
    проектов, установленного образца,
  4.5.2.   Контроль инициации  и хода выполнения проектов в соответствии с Матрицей ответственности ( см приложение №1)
  4.5.3.   Проверка соответствия подготовки проектных документов  Стандарту управления проектами, в том числе входной контроль наличия пакета проектных документов в соответствии со Стандартом управления проектами.
  - паспорт проекта, включая Перечень рисков и План коммуникаций.
  - Календарный план проекта
  - Бюджет проекта
  - Соглашение с Заказчиков по реализации проекта.
  4.5.4. ПЦ контролирует отчетность  и ход  выполнения проектов, находящийся на администрировании или выполнении в Региональном представительстве.
   4.5.5. Исполнение документооборота между ПЦ и Региональным  
  представительством.
  4.5.6. Администратор Регионального представительства обязан вести документооборот в соответствии со Стандартом управления проектами и информировать администрацию ПЦ о всех возникающих форс-мажорных или иных ситуациях не предписанных стандартом максимально оперативно.
   Взаимодействие Проектного Центра со структурными подразделениями компании (схема взаимодействия, документы).
   
  Исп. Дир.;
  Ген. Дир.
   
   
  ПЦ
  -   Паспорт проекта;
  -   Концепция проекта;
  -   План коммуникаций;
  -   Распоряжение о предпроектно й проработке с визой о причине несогласования или о разработке приказа о запуске проекта;
  -   Приказ об открытии проекта
   
   
  Запись в реестре проектов «Проект отложен», «Проект отклонен», «Проект открыт»
   
   
  Все заинтерес. лица в соотв. с планом коммуникаций
   
   
   
  Исп. Дир.
   
  ПЦ
  Поручение о разработке распоряжения о предпроектной подготовке
   
  Распоряжение о предпроектной подготовке
   
   
  Дирекции реализации проектов; Руководитель предпроектной подготовки
   
  ПЦ
   
   
   
   
  Ген. Дир.
   
   
  ПЦ
  Утвержденные документы: План по вехам, Реестр рисков, Бюджет проекта
   
   
  Запись в реестре проектов об имеющихся документах
  Запись в реестре проектов об имеющихся документах
  Информация в соотв. с планом коммуникаций
   
   
  Дирекции реализации проектов; Руководитель предпроектной подготовки
   
   
  ПЦ
  Скорректированный и утвержденный план проекта
   
   
   
  Ген. Дир.
  Исп. Дир.
   
  ПЦ
  Реестр поручений; материалы к совещаниям
  Дирекции реализации проектов; Руководитель предпроектной подготовки
  Поручения ген. Дир., Исп. Дир., материалы к совещаниям
   
   
  ПЦ
  Реестр рисков; Материалы к совещаниям
   
   
   
   
  Фин. Дир.
   
  ПЦ
  Отчеты по бюджетам проектов
  -   Дирекции реализации проектов; Руководитель предпроектной подготовки;
  -   Ген. Дир,
  -   Исп. Дир.
  Консолидированный отчет по проектам
   
   
  ПЦ
   
   
   
   
   
  Дирекции реализации проектов
   
  ПЦ
  Отчеты по календарным планам проектов
  -   Дирекции реализации проектов; Руководитель предпроектной подготовки;
  -   Ген. Дир,
  -   Исп. Дир.
  Консолидированный отчет по проектам
   
   
  ПЦ
   
   
   
   
   
  Руководитель проекта
   
  ПЦ
  Запрос на изменение
  -   Дирекции реализации проектов;
  -   Ген. Дир,
  -   Исп. Дир.
  Реестр изменений
   
   
  ПЦ
  Реестр изменений
  Запрос  на изменение с отметкой «Принято»
   
   
   
  Руководитель проекта
   
  ПЦ
  Измененные: календарный план, Бюджет, План по вехам
  Измененные: календарный план, Бюджет, План по вехам
   
   
  Все заинтерес. лица в соотв. с планом коммуникаций
   
   
   
  Исп. Дир.,
  Ген. Дир.
   
  ПЦ
  Распоряжение об окончании работ по проекту;
  Приказ о завершении работ по проекту
  Реестр проектов
   
   
  Все заинтерес. лица в соотв. с планом коммуникаций
   
   
   
  Фин. Дир.
   
  ПЦ
  Фин. Отчет о реализации проекта
  Все заинтерес. лица в соотв. с планом коммуникаций
  Реестр проектов
   
   
   
  ПЦ
  Взаимодействие с Региональными представительствами
  Все заинтерес. лица в соотв. с планом коммуникаций
  Реестр проектов
  Администратор
  Руководитель проекта
  Дирекции реализации проектов; Руководитель предпроектной подготовки
  Директор Регионального представительства
  Реестр проектов
   
   
  5. Документирование и внесение изменений.
  МАТРИЦА ОТВЕТСТВЕННОСТИ взаимодействия ПЦ с региональными представительствами
  Событие/результат
  Директор проектного центра
  РОЭЛ ПиФ
  Директор регионального представительства
  Администратор проектного центра
  РОЭЛ Пиф
   
  Администратор регионального представительства
  Руководитель проекта
   
  Приказ о предпроектной подготовки
  Утв.
  С
  К
  У
  И
  Приказ об открытии проекта
  Утв.
  С
  К
  У
  И
  Календарный план
  Утв.
  С
  К
  У
  И
  Паспорт проекта
  Утв.
  С
  К
  У
  И
  Концепция проекта
  Утв.
  С
  К
  У
  И
  Бюджет проекта
  Утв
  С
  К
  У
  И
  Отчетность по проекту
  Утв.
  С
  К
  У
  И
  Инициирование изменений в ходе реализации проекта
  Утв.
  С
  К
  У
  У
  Принятые сокращения
  И – исполняет С – согласовывает  К   – контролирует
  У   -  участвует Утв - утверждает
   
   
  № шага
  Действие
  Краткое описание
  Ответственные
  Входящие документы
  Исходящие документы
  Кому предоставляется
   (куда)
  Периодичность
  1
  Инициирование проекта Региональном представительством
  Проект который ведется в региональном представительстве должен быть оформлен в соответствии со Стандартом управления проектами
  Руководитель проекта
  Приказ о проекте или предпроекте, установленного Стандартом управления проектами образца
  После подписания Приказа о старте  проекта или предпроекта вносится запись в Единый реестр.
  ПЦ
  По мере возникновения необходимости
  2
  Передача проекта на исполнение в Региональное представительство
  Директор Регионального представительства представляет кандидатуру Руководителя проекта на утверждение в ПЦ РОЭЛ. После утверждения кандидатуры Руководителя проекта Директором ПЦ. Руководитель находится в административном подчинении Директора дирекции в юрисдикции которой ведется проект.
  Директор Регионального представительства, Руководитель ПЦ
  Приказ о назначении руководителя
  Кадровые документы установленного  образца.
  ПЦ
  По мере возникновения необходимости
  3
  Администрирование проекта в Региональном представительстве,
  Администратор Регионального представительства ведет документооборот в соответствии со Стандартом управления проектами.
  Администратор Регионального представительства, Администратор ПЦ ПиФ
  Реестр проектов ПЦ ПиФ, Стандарт управления проектами
  Документы регламентирующие  ход выполнения проекта
  ПЦ ПиФ
  При возникновении проекта
  4
  Контроль  отчетности и хода выполнения проекта в Региональном представительстве
  Согласно Стандарту управления проектами  Администратор Регионального передает информацию в стандарте единого реестра в ПЦ ПиФ
  Администратор Регионального представительства, Администратор ПЦ ПиФ
  Формы отчетности установленного ПЦ ПиФ
  Ежемесячные отчеты.
  ПЦ ПиФ
  Ежемесячно, до 10 числа месяца следующего за отчетным
   
  [1] США, Свод знаний по управлению проектами (PMI)
  [2] Английская ассо­циация проект-менеджеров
  [3] Германия — DIN 69901
  [4] Анисимов С.Н. Управление проектами. Российский опыт [Текст]/С.Н.Анисимов. Е.В.Анисимова.- СПб.: Вектор,2006 стр.31
  [5] Эдвард Деминг (W. Edwards Deming) - величайший ученый 20-го века, работавший в об­ласти управления качеством.  Предложенные им статистические методы и общие философские подходы нацелены на повышение предсказуемости большинства процессов. В частности, по Демингу, система считается остающейся под контролем, если она достигает стоящих перед нею целей в 95% случаев
  
Скачать дипломную работу