Матрична організаційна структура

На прохання групи товаришів починаю публікацію коротких оглядів основних типів організаційних структур. Почну з матричної.

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

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

ПЕРЕВАГИ
1. Більш ефективне, ніж в традиційній ієрархії використання ресурсів.
2. Гнучкість, адаптивність до навколишнього середовища.
3. Розвиток як загальної, так і спеціальної підготовки.
4. Збагачення змісту робочих завдань для всіх співробітників.
НЕДОЛІКИ
1. Плутанина і фрустрації, викликані порушенням принципу єдиноначальності.
2. Можливість гострих протиріч між сторонами матриці.
3. Складність координації проектних груп.
4. Необхідність навчання співробітників мистецтву людських відносин.

Впровадження матричної структури дає хороший ефект в організаціях з досить високим рівнем корпоративної культури і кваліфікації співробітників, в іншому випадку можлива дезорганізація управління (на фірмі «Тойота» впровадження матричної структури зайняло близько 10 років). Ефективність втілення в життя ідей сучасної філософії якості в такій структурі доведена практикою фірми «Тойота».

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

Якщо у Вас є приклади подібного «співжиття», то буду вдячний за опис.

)))
Спасибі, Галина, але можна було і не лестити. ;)))
* * *
Думаю я кілька «приземлено» - стосовно тієї практики, що зустрічаю кожен день в офісі, а знань, якщо чесно, не вистачає.
Тому деякі речі мені трохи важко розглядати у відриві від повсякденної діяльності.

А в статті принципи явно не для СМБ.
Однак управління проектами треба вивчати в будь-якому випадку - хоч ПМ і підходить більше для великого бізнесу, але
щось підійде і для більш скромних організацій.

ПС
Для мене таке спілкування, перш за все, служить як нагадування про те, що, за великим рахунком, знаю я дуже мало і треба багато чому вчитися.
Ну і як покажчик чому вчитися.
* * *
З наступившим новим роком!

Суперечки немає. Я просто відповідала на Ваші питання в міру їх надходження ... До речі, робила це з задоволенням - завжди приємно поговорити з думаючим (!) Людиною. Якщо б Ви були «думаючим», то і питань би у Вас не виникало, бесіди не вийшло б. А так - мені було дуже приємно з Вами поспілкуватися, Ви цікавий співрозмовник. І ті питання, які Ви ставили допомогли повніше розкрити тему. Це завжди добре.

З повагою,
Галина

🙂
ОК.
Повернемося до цього питання після того, як я все-таки доберуся до повноцінного вивчення менеджменту та управління проектами. Бо назріло.
А зараз, якщо чесно, я втратив суть спору.
А про що суперечка?
Я просто запитав…

Czyan!
Спробую і я пояснити на прикладах. Життя людини - це процес. Причому в класичному розумінні процесса.Так? Протягом життя кожен з нас реалізує масу проектів. Тобто проекти входять в процес. Це з одного боку. З іншого - скористаюся прикладом Олексія Васильовича з проектом "Святкуємо Новий рік разом". Це унікальний «продукт», тому що робиться раз на рік і по-різному. Однак в цей проект входить маса процесів. Наприклад - процес приготування салату «Олів'є» - стандартний набір продуктів, пропорцій, послідовність виконання операцій, конкретне кількість часу і т.д. Є ще й процес «нарядити ялинку» ... Тобто всередині проекту - процеси. Поки все зрозуміло? Тепер поясню, навіщо я Вам всім цим голову морочу. Справа в тому, що НЕ структура підприємства визначає його діяльність. А під діяльність підприємства вибирається оптимальна структура. А тому і проекти, і процеси все одно завжди існують разом, але в різній мірі (.), то задача зводиться до того, що б визначити - яку структуру для конкретної діяльності підприємства вибрати - чого в ній більше (в діяльності) проектів або процесів, і чи можна чимось принебречь? Якщо це разові унікальні продукти - то проектна структура краще, хоч, напевно, все ж існує якийсь стандартизований процес виготовлення чогось всередині кожного такого проекту. Якщо ж це якийсь потокове виробництво товару, то доречніше одна з різновидів функціональної системи. Питання - а навіщо потрібна матрична? Відповідь - тільки така структура дозволяє ОДНОЧАСНО використовувати і процессное і проектне управління діяльністю підприємства. Застосовувати матричну структуру підприємства економічно виправдано тільки в тому випадку, коли дійсно і проекти і процеси «працюють» спільно. У всіх інших випадках накладні витрати (приклад) зведуть нанівець всю ефективність роботи підприємства. Тому перш, ніж вибирати структуру управління діяльністю підприємства, необхідно для цього зробити цілий ряд економічних розрахунків.
Що ж стосується різного роду документів процесного управління (карта процесу, інструкція якості) або проектного (статут проекту, план управління проектом), то навіть коли ми їх не пишемо, наприклад в побуті, подумки все одно маємо. Рецепт салату Олів'є - карта процесу. Список заходів і їх тимчасові рамки для святкування Нового року - план управління проектом.
Все просто, коли розумієш ЩО робиш.

З повагою,
Галина

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

У Вашому прикладі немає унікальності. Але Ви маєте право називати це проектом, очікую, що ні Петров, ні Сидоров, ні майстер Вас не зрозуміють. Чи не зрозуміють і люди, знайомі з такою галуззю знань, як управлінням проектами.

Погоджуся, що «Для створення проекту зовсім необов'язково використовувати такі формалізовані інструменти, як статут проекту або накази і спеціалізовані посадові інструкції». Однак результат реалізації проекту буде на голову вище, в разі використання світового досвіду організації цього процесу.
АВМ

Для створення проекту зовсім необов'язково використовувати
такі формалізовані інструменти, як статут проекту або накази і спеціалізовані посадові інструкції.

приклад:
Майстер каже робочому: «Візьми Петрова і Сидорова і очистіть майданчик перед цехом, а то захарастили сильно. Сміття викинете, оті ящики автонавантажувачем відвезіть туди. Термін - 2 дня. »
У цьому проекті у нас є ресурси, персонал і терміни.

В частині того, що сліди перехресної взаємодії та проектної організації можна знайти в будь-якій організації, це вірно. Наприклад, проект «Святкуємо Новий рік разом». Однак розмір має значення. Проектний менеджмент, наприклад, встановлює мінімальні вимоги до проекту щодо термінів, вартості. Реалізація проекту передбачає вимоги до процесів його реалізації (проектний офіс, статут проекту та ін.). У побуті ми маємо право називати проектом будь-які нововведення, навіть найнезначніші. Однак для цього не обов'язково створювати спеціальні структури і використовувати спеціальні методи. Чи не ефективно.

Хм ...
Якщо розглядати будь-яке підприємство, то в ньому можна знайти як сліди матричної організації, так і проектної.
І розмір значення не має.
Будь-яке скільки-небудь тривалий дію є проектом.

Czyn!
Спробую пояснити. Є кілька функціональних відділів (конструктора, проектувальники, програмісти, монтажники тощо). У кожного такого підрозділу свій начальник (власник ресурсів). Є «Бюро менеджерів проектів» (власники проектів). ВСЕ (.) Функціональні відділи працюють по ВСІХ (.) Проектам ОДНОЧАСНО, кожен відділ в відповідність зі своєю спеціалізацією (функцією). Але! Усередині кожного функціонального відділу є ще свої сектора зі своєю специфічною подфункціеей (математики, наприклад). І кожна людина в такому секторі в свою чергу спеціалізується на якійсь певній групі завдань. Тобто кожен співробітник відділу працює по декількох проектах одночасно, але в рамках своєї функціональної спеціалізації. Завдання власників проектів зводиться до того, що б видати завдання функціональних відділів (!) На проведення тих чи інших робіт. Завдання начальника відділу розподілити роботи, отримані від різних власників пректов, по своїм підлеглим в залежності від їх спеціалізації та завантаженості (управління ресурсами).

Якщо грамотно розписати повноваження власників проектів та власників ресурсів двовладдя можна нівелювати.

З описаного вище, сподіваюся, зрозуміло, що така матрична структура доцільна до застосування тільки для великих (м.б. середніх) підприємств, що працюють в процесному режимі, що випускають однотипну (!) Проектну продукцію в більших обсягах.

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

Але про це Вам пізніше розповість Олексій Васильович. Може бути, і я підключуся ...

З повагою,
Галина

Спасибі, як виглядає проектна група мені відомо.
Однак моє запитання залишився незрозумілим:

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

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

На час виконання бойового завдання і / або до отримання окремого наказу танкісти і розвідники підкоряються піхотному командирові.
В цей час зі своїми «попередніми» командирами вони
не взаємодіють.

Аналогічно реалізується і в цивільній схемою.

Проектна організація це інший тип організаційної структури. Про це я планую написати пізніше. Проектна організація - це тимчасова структура, створювана для вирішення конкретного завдання. Сенс її полягає в тому, щоб зібрати в одну команду найкваліфікованіших співробітників організації для здійснення складного проекту у встановлені терміни з заданим рівнем якості, не виходячи за межі встановленої кошторису. Коли проект завершено, команда розпускається. Її члени переходять в новий проект, повертаються до постійної роботи у своєму «рідному» відділі або йдуть з цієї організації. Але про це пізніше.

Таке питання - а чому не можна виключити проектну частину?
Тобто є матриця, але проектні групи не організує?

Варіант 2
На час проведення проекту людина випадає з матриці.
В цьому випадку ми виключаємо конфлікт ресурсів.