Методичні вказівки до виконання курсової роботи

МЕТОДИЧНІ ВКАЗІВКИ

ДО КУРСОВОЇ РОБОТИ

Затверджено на засіданні кафедри УПББМ,

протокол № ___ від „_____________” 2014 р.

Зав. кафедрою УПББМ, професор О.М. Пшинько

Розробник: доцент каф УПББМ І.О. Гордєєва

У курсовій роботі повинні бути представлені результати розробки структури та формування основних планових рішень обраного проекту (програми).

Результати структуризації проекту представляються за допомогою таких інструментів, як WBS, OBS, RBS, CBS, матриця відповідальності, CTR-словник.

Методичні вказівки до виконання курсової роботи

Після завершення концептуальної фази проекту отримано чітке уявлення про його суть, цілі і завдання, які він повинен вирішувати. Проект перейшов на стадію планування.

На даній стадії була виконана структуризація проекту. Для кожного учасника сформований перелік робіт і необхідних для їх виконання ресурсів, визначені проміжні і кінцеві результати, які мають бути отримані при виконанні робіт. Між всіма роботами проекту встановлені раціональні зв'язки.

Для структуризації проекту застосований ряд спеціальних моделей:

– структура робіт (WBS);

– організаційна структура (OBS);

– матриця відповідальності (RAM);

– структура ресурсів (RBS);

– структура витрат (CBS).

Структура розбиття робіт (WBS)

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

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

• Структурная декомпозиция работ (СДР)
• Иерархическая структура работ (ИСР)
• Work breakdown structure (WBS).

Мы декомпозируем проект: разбиваем его на составные части по какому-либо признаку. Обычно применяют следующие виды WBS:

• Продуктовая, когда проект разбивается по элементам продукта проекта

Фрагмент структурной декомпозиции работ проекта (WBS) по элементам продукта проекта

• Функциональная: декомпозиция по функциональным областям менеджмента

Фрагмент структурной декомпозиции работ проекта (WBS) по функциям менеджмента

• По этапам жизненного цикла проекта

Фрагмент структурной декомпозиции работ проекта (WBS) по этапам жизненного цикла

• Могут быть и другие, в том числе смешанные типы.

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

Есть несколько принципов построения структурной декомпозиции работ:

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

– WBS строится по принципу правильного дерева, т.е. у одной ветки/листа может быть только один «родитель».

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

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

Приклад Структура WBS представлено на рис. 1.

WBS-структура побудована за фазами життєвого циклу проекту, а саме фази концепції, планування, виконання та завершення. Найбільш трудомістким є третя фаза – фаза виконання, що включає два основних пакети робіт: розробку проекту положення про організаційну культуру станції Бахчисарай та впровадження інструментів інформаційного впливу «Team Buildings» на станції Бахчисарай. До розробки положення про організаційну культуру станції Бахчисарай входить: оцінка існуючої організаційної культури, виявлення недоліків, розробка проекту положення про організаційну культуру станції Бахчисарай, представлення пропозицій керівництву станції, внесення змін (за необхідності), підписання наказу, що затверджує положення про організаційну культуру станції.

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

Після того, як будуть розроблені положення про організаційну культуру на станції Бахчисарай та формування в них інструментів інформаційного впливу "Team Buildings" ці інструменти будуть впроваджуватися на станції та буде вже проводитися роботи із персоналом.

Інструменти інформаційного впливу "Team Buildings" будуть складатися із:

– заснування та проведення свята "День станції Бахчисарай", який буде направлений на формування сильного командного духу, єдності колективу, інформації про цілі станції. На цьому святі буде проведено святковий концерт, де співробітники зможуть проявити свої таланти (співи, танцювальні виступи, виставити свої результати рукоділля, вишивки, збірники віршів та творів, картини та інше).

– проведення лекцій з історії та цінностей станції на нарадах.

– видання електронного журналу про новини станції (в якому буде публікуватися інформація про успіхи станції, про кращих співробітників, про свята та зустрічі керівництва станції з партнерами та інше). Цей журнал співробітниками профспілки буде розсилатися на електронну пошту співробітників.

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

– поширення міфів про станцію, про діяльність станції в період Вітчизняної війни, її героїв та героїчні вчинки звичайних людей.

політика, поведінка та вчинки керівництва станції та співробітників.

Рис. 1. WBS-структура робіт проекту

Організаційна структура (OBS)

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

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

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

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

Рассмотрим их более детально.

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

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

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

Рис. 2 Пример функциональной организационной структуры

Примечание: цветом выделены сотрудники, участвующие в проекте.

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

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

Рис. 3 Пример проектной организационной структуры

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

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

Случай из практики. Подобное произошло с крайне успешной командой разработчиков компьютеров Макинтош из фирмы Apple. Стив Джобс, совмещавший в то время посты председателя Аррlе и управляющего проектом Макинтош, щедро стимулировал свою команду, члены которой могли, например, пройти сеанс массажа прямо на работе, пили только для них свежевыжатый апельсиновый сок, могли развлечься и летали только первым классом. Ни один другой работник Apple не летал первым классом. Джобс считал свою команду элитой Apple, а всех остальных называл работниками второго сорта. Инженеры из подразделения Apple II, которые приносили Apple огромную прибыль от продаж, пришли в ярость от подобного отношения. Однажды в местном баре напряженность между инженерами Аррlе II, сидящими за одним столом, и сидящими за другим столом представителями команды «Мас», выплеснулась наружу. Арон Голдберг, давно работающий консультантом в компании, наблюдал за усиливающейся перепалкой. «Ребята из «Мас» кричали, что они – «будущее компании». Ребята из «Аррlе II» кричали, что они – «деньги компании». Затем полетели ручки и карандаши. Я ждал, когда же наконец упадут бумаги, и они накинутся их собирать».

Хотя со стороны это могло показаться забавным, но драка между группами «Аррlе II» и «Мас» серьезно подорвала работу Аррlе в 1980 годах. Джон Скалли заменивший Стива Джобса на посту председателя Аррlе, сказал, что корпорация, превратилась в две «воюющие компании», и назвал улицу между зданиями «Аррlе II» и «Масintosh» «демилитаризованной зоной».

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

Рис. 4 Пример матричной организационной структуры

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

Разновидностью функциональной организационной структуры является дивизиональная организационная структура. Исторически дивизиональные структуры появились в крупных многопрофильных корпорациях. Пионерами во внедрении дивизиональных структур в 20-х годах XX столетия стали компании «Проктер энд Гембл», «Дженерал Моторс», «Дюпон», «Сирс». Опыт выявился настолько удачным, что уже к концу 60-х годов более 75% компаний из списка «Fortune 500» использовали дивизиональную структуру.

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

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

Рис. 5 Пример дивизиональной организационной структуры

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

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

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

В принципе, функциональная и дивизиональная структуры отличаются только объемом делегируемых полномочий, четкой грани между ними нет. С точки зрения повышения эффективности предприятия дивизиональная организационная структура обеспечивает, по сравнению с функциональной, снижение уровней иерархии в управлении на один уровень. Однако Джеку Уэлчу, руководившего компанией «General Electric» с 1981 г. по 2001 г. удалось снизить число уровней иерархии с 29 до 6 (!), при этом сократив численность с 440000 до 313000 человек и повысив прибыль с 1,65 млрд. долларов до 7,3 млрд долларов! Так что основной путь повышения эффективности предприятия в условиях динамичной среды – это, в первую очередь, снижение числа уровней иерархии и переход к плоским организационным структурам.

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

– идентификацию всех организационных единиц;

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

– распределение ответственности и полномочий между организационными единицами структуры;

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

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

Таким образом, подводя итоги можно сказать, что планирование в проекте того «Кто это будет делать?» выполняется по двум направлениям:

1. Формирование команды управления проектами, определение связей между ее членами, уровней ответственности;

2. Формирование связей команды проекта и материнской организации.

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

Рис. 2. OBS-структура проекту

Команда проекту буде сформована із працівників станції Бахчисарай.

До складу команди проекту увійдуть:

– Керівник проекту (функції якого за сумісництвом буде виконувати начальник станції Бахчисарай);

– Працівники профспілки;

– Менеджер з персоналу (функції якого за сумісництвом буде виконувати старший інспектор з кадрів станції Бахчисарай).

Залучення членів команди проекту відбувається за матричною організаційною структурою. Матрична організаційна структура передбачає, що співробітники працюють на своїх основних посадах та додатково виконують функції в проекті. Як відомо, виділяють сильну, слабку та збалансовану різновиди матричної організаційної структури: сильна, коли більшу владу має керівник проекту; слабка, коли більшу владу мають керівники функціональних підрозділів; збалансована – це коли, намагаються збалансувати владу керівника проекту та функціональних менеджерів на працівників, що входять до команди проекту. Найбільш раціональною у разі підприємства, що досліджується, організувати діяльність членів команди за збалансованою матрицею.

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

А залучення до проекту начальника станції Бахчисарай дозволить мати оперативну інформацію по проекту та забезпечити відповідальне відношення.

Передбачено, що працівники 30% робочого часу щоденно будуть залучені до проекту, а інші 70% часу ці працівники будуть виконувати свої посадові обов’язки.

Як видно із рис. 3.2 начальник станції Бахчисарай буде поєднувати посаду керівника проекту.

Проектом не передбачено залучення сторонніх спеціалістів.

Матриця відповідальності (RAM)

Матриця відповідальності (RAM), ставить у відповідність ієрархічну структуру робіт (WBS) і організаційну структуру (OBS) для призначення відповідальних на всі пакети робіт проекту забезпечує опис і узгодження структури відповідальності за реалізацію робіт за проектом з вказівкою ролі кожного учасника в їх виконанні.

Таблица 3. – Матрица ответственности (RAM)

При розробці матриці відповідальності проекту використана методика RACI. Методика RACI є зручним і наочним засобом планування відповідальності членів проектної команди при виконанні завдань на кожному з етапів проекту. Термін RACI (або ARCI) є абревіатурою:

Відповідальний (Accountable) – повністю відповідає за виконання етапу/завдання, має право приймати рішення за способом реалізації. Відповідальним за завдання може призначатися лише одна людина.

Виконавець (Responsible) – виконує завдання, не несе відповідальність за вибір способу його рішення, але відповідає за якість і терміни реалізації. В кожного завдання має бути хоча б один виконавець.

Затверджувач (Consult before doing) – надає консультації в ході рішення завдань проекту, контролює якість реалізації. Та людина, яка ухвалює деякий документ (якщо дана робота пов'язана із створенням документа). Він може бути лише один.

Узгоджувач (Inform after doing) – може надавати консультації в ході рішення завдань проекту, не несе відповідальності. Особа, яка бере участь в узгодженні деякого документа (якщо дана робота пов'язана із створенням документа). Їх може бути декілька.

Для зручності введемо короткі позначення по першим буквам відповідальностей (окрім першої відповідальності, так як відповідальний і виконавець починаються з однієї букви):

О – відповідальний;

В – виконавець;

З – затверджував;

У – узгоджувач.

Приклад. Матриця розподілу відповідальності проекту RAM з врахуванням функціональної організаційної структури організації приведена в таблиці. 3.