Матриця відповідальності управління проектами приклад. Визначення ролей проекту. Фактори зовнішнього середовища

Матриця відповідальності проекту

Для відображення ієрархії підзвітності на проекті і вказівки обов'язків кожної з груп, що входять в проектну команду, в документ опису змісту проекту рекомендується включити матрицю відповідальності, Найбільш поширений варіант якої відомий як RACI-матриця. Використання даного інструменту особливо актуально в ситуації, коли проектна команда   складається з представників різних юридичних осіб (наприклад, типова команда   на проект впровадження КІС включає в себе співробітників замовника, генерального підрядника і субпідрядників). матриця відповідальності   переймається тим демонстрації Міжорганізаційні або міжгрупового взаємодії   і, як наслідок, дозволяє уникнути непорозумінь, які час від часу виникають у проектах між підрозділами і організаціями через неясність, до кого слід звертатися з тих чи інших питань і хто повинен приймати по ним рішення, а хто - безпосередньо реалізувати прийняту резолюцію.

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

Побудова матриці відповідальності

Перерахувати основні роботи проекту.

По вертикалі в матриці відображаються тільки основні роботи проекту (не нижче рівня 2-3 ІСР), Але з достатнім ступенем деталізації для забезпечення можливості вказувати різні ролі, необхідні для виконання цих робіт. Коли мова йде про великі проекти і програми, може виникнути необхідність розробити кілька матриць відповідальності   з різним ступенем деталізації.

Перерахувати групи / ролі всередині проектної команди.

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

закодувати матрицю відповідальності.

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

Таблиця 6.1. Умовні позначення матриці відповідальності   (RACI)
позначення	розшифровка		опис
	Виконавець (Responsible)		Несе відповідальність за безпосереднє виконання завдання. До кожного завдання повинно бути приписано не менше одного виконавця Найбільш поширене використання матриць відповідальності - в управлінні проектами, де вони забезпечують наступні переваги. Визначає узгоджену відповідальність за все ролі в досягненні конкретного проекту або завдання. Визначає ролі і обов'язки, гарантуючи, що кожен знає, хто повинен робити те, що допомагає забезпечити участь відповідних груп. Допомагає усунути дублювання зусиль. Зменшує ризик непорозуміння. Визначає відповідальність за прийняття рішень за все завдання. Матриця відповідальності - відмінний спосіб додати додаткову інформацію в вправа для зіставлення процесів.
	Який стверджує (Accountable)		Відповідає за кінцевий результат перед вищим керівництвом. На кожну роботу повинен бути призначений строго один підзвітний
	Узгоджувальний (Consulted)		Погодить прийняті рішення, взаємодія з ним носить двосторонній характер Почавши з матриці відповідальності процесу «як є» вище, бізнес-аналітик тепер має велику інформацію, яка допоможе їм перебудувати процес. Матриця може допомогти їм визначити потенційні вузькі місця процесу, а при розробці нового процесу може бути створена нова матриця, яка відображає нові рівні відповідальності. Потім старі і нові матриці можна порівняти, щоб гарантувати, що завдання, етапи або зацікавлені сторони не будуть виключені з нового процесу. Визначення та аналіз рішення Як і використання зіставлення процесів вище, створення матриці відповідальності при аналізі організації допомагає бізнес-аналітику краще зрозуміти, хто що робить і хто має якісь обов'язки. У матриці має зазначатися, хто «володіє» заявою, хто підтримує додаток, якому належать системи, від яких залежить новий додаток або залежить від нової програми, і хто зацікавлений в знанні про зміни в додатку або його статус.
	Спостерігач (Informed)		Його інформують про вже прийняте рішення, взаємодія з ним носить односторонній характер
Таблиця 6.2. Розподіл функціональних обов'язків команди управління проектом
Функціональні обов'язки При розгляді змін в існуючій системі матриця відповідальності для цієї системи може допомогти забезпечити залучення всіх зацікавлених сторін в обговорення і вирішення. Матриця відповідальності «як є» пов'язаних з поточною діяльністю, бізнес-одиниці або організації може бути неоціненним інструментом, що допомагає новим співробітникам зрозуміти відповідальність за нову роль, яку вони виконують, і як ця роль вписується в загальний бізнес-процес. У поєднанні з «майбутньою» матрицею це особливо корисно для навчання існуючих співробітників, щоб зрозуміти, які зміни відбуваються в рамках нового процесу або розгортання системи.		Куратор проекту (Спонсор)		Керівник проекту	архітектор системи	Адміністратор проекту
планування
Розробка і періодична актуалізація плану Створення матриці відповідальності - це відносно простий процес, який слід за наступними кроками. Визначте завдання або результати, які повинні бути виконані, щоб результат був досягнутий. Якщо у вас є, то для цього важливо створити структуру розбивки на роботу. Перерахуйте їх по лівій вертикальній осі матриці; переважно в тому порядку, в якому вони повинні виконуватися. Визначення ролей проекту Вирішіть, призначаєте ви відповідальність за ролі або фактичних іменованих осіб. Потім перерахуйте ролі або імена в верхній частині матриці, по одному на стовпець. Виберіть схему матриці відповідальності, яка найбільш підходить для ваших потреб. Потім пройдіть через матрицю, розглядаючи кожну задачу по черзі. Для кожного завдання вкажіть рівень відповідальності кожної ролі, ввівши велику літеру, яка вказує рівень відповідальності цієї ролі в досягненні завдання. Якщо ви не використовуєте схему, що включає рівень відповідальності опущених, не кожна роль повинна мати призначений рівень відповідальності.
затвердження плану
Управління командою проекту
Призначення співробітника на роль Керівника проекту Наступний крок часто буває найскладнішим. Це не просто огляд діаграми, а й забезпечення того, щоб всі сторони, які беруть участь в проекті або зусиллях, розуміли рівень відповідальності, якому вони були призначені, і згодні з цим завданням. Чи мають люди, які виконують ролі, особливо ті, хто проводить консультації або поінформовані, мають занадто багато навичок або стаж роботи? Охоплюють чи рівні відповідальності занадто багато уваги і часу і чи можуть делегуватися ролі? Якщо немає, чи дійсно ця роль справді повинна бути задіяна в цьому? Чи повинно більш старше особа бути призначено на цю роль? У кожній ролі є хоча б деякий рівень відповідальності, крім опущеними? Можуть відбутися зміни в ресурсах проекту, або ваші знання про завдання можуть змінитися.
Формування команди проекту
Визначення кваліфікаційних охоронних вимог і складу робочих груп фахівців з функціональності ІС
Забезпечення виділення необхідних ресурсів для виконання проекту Все це може потребувати оновлення матриці відповідальності. Коли матриця відповідальності буде завершена, ви повинні були домогтися наступних результатів. Кожен залучений людина повинна розуміти і погоджуватися з ролями і обов'язками, які вони були призначені для досягнення цих зусиль. Матриці відповідальності є неоціненними інструментами для зусиль по управлінню зацікавленими сторонами, оскільки вони забезпечують, щоб усі зацікавлені сторони знали і згодні з тим, які обов'язки вони мають для проекту. Допомога гарантує, що в разі оборотності проекту новий ресурс знає про їх обов'язків цивільного характеру або допомагає повторно призначити обов'язки минає ресурсу. Вони відносно прості в створенні і можуть бути використані в різних сценаріях, не пов'язаних з проектом. Процес переходу до узгодженої матриці відповідальності може бути бурхливою, якщо є розбіжності між зацікавленими сторонами щодо того, що вони вважають своєю роллю або обов'язками, в залежності від того, яку роль або обов'язки їм призначають. Легко загрузнути в спробі визначити кожну можливу завдання перед тим, як проект почнеться. Це може бути як побічним проектом, так і подальшим обговоренням зацікавленими сторонами. Можливо, ви захочете розглянути колірне кодування осередків матриці за рівнем відповідальності, щоб зробити її більш зрозумілою з першого погляду. Необхідно визначити всі завдання, необхідні для зусиль. Необхідно визначити всі ролі, необхідні для завершення завдань. Це може привести до того, що матриця буде виглядати так. Стаття управління проектом Карен Дейві-Зима.
Безпосереднє керівництво Командою проекту
Формування пропозицій щодо стимулювання Команди проекту
Забезпечення стимулювання Команди проекту Є багато видів команд. Функціональна команда - постійна команда, створена для проведення оперативної діяльності для певної частини організації, таких як фінанси, продажі, маркетинг і т.д. Для функціональних команд немає певного обмеження за часом, оскільки вони необхідні для підтримки роботи бізнесу. Команда проекту об'єднується протягом дискретного періоду часу для досягнення певної мети. В кінці проекту команда розформована. Проектні групи часто мають характерний характер, укомплектований членами з різних функціональних груп для досягнення мети проекту. Коли керівник проекту має високий ступінь авторитету, він відомий як сильна матриця; коли функціональні менеджери мають сильніший авторитет, це називається слабкою матрицею.
Організація виконання робіт
Організація взаємодії з Замовником і забезпечення всіх необхідних комунікаційних зв'язків з іншими учасниками проекту
Організація підготовки, погодження та затвердження всієї технічної документації, Необхідної для створення ІС в рамках проекту
Організація, проведення та документування процедур передачі Замовнику розробленої ІС
Розгляд та затвердження регламентуючих документів, необхідних для організації і виконання проекту
Ведення організаційно-розпорядчої та звітної документації. Підтримка в актуальному стані списку команди проекту
Забезпечення команди проекту необхідними інформаційними матеріалами
Матеріально-технічне та господарське забезпечення команди проекту
Контроль ходу виконання проекту
Організація і проведення нарад з обговорення ходу робіт проекту
Підготовка та надання Кураторові звітів про хід робіт проекту
Отримання і аналіз зведеної звітності про хід реалізації проекту
Контроль відповідності результатів проекту Технічного завдання на розробку ІС
Узгодження фактичних трудовитрат фахівців при виконанні проекту

На коди, що використовуються в матриці відповідальності, Будь-яких обмежень не існує, але найбільшого поширення набув метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed (I)), в якому наведено опис відповідних кодів.

Ініціювати використання матриці і включити процедуру використання матриці відповідальності   в документ " План управління проектом".

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

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

Зокрема, матриця відповідальності   може бути використана для розподілу основних функціональних обов'язків. Так, в табл. 6.2   в лівому стовпчику перераховані функціональні обов'язки, відповідні проектні роботи, список яких складено на основі використовуваної методології і накопиченого проектного досвіду, а в праву частину таблиці вноситься відмітка про ступінь відповідальності і участі кожного з члена групи управління проектом у виконанні відповідної функції.

Закріплення функцій і повноважень в проекті

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

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

Основні функції:

загальне керівництво ходом реалізації проекту;

забезпечення виділення необхідних ресурсів для виконання проекту, забезпечення фінансування робіт;

розгляд та затвердження регламентуючих документів, необхідних для організації і виконання проекту;

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

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

Основні повноваження:

твердження цілей проекту;

погодження призначення керівника проекту;

твердження загального плану і бюджету проекту;

отримання від керівника проекту зведеної звітності про хід його виконання;

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

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

Основні функції:

формування команди проекту і команди управління проектом;

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

розподіл ресурсів проекту і організація взаємодії команди проекту в процесі його виконання;

організація взаємодії з замовником та забезпечення всіх необхідних комунікаційних зв'язків з іншими учасниками проекту;

облік фактичних витрат ресурсів по виконанню проекту;

формування та надання куратору звітності за проектом.

Основні повноваження:

призначення завдань команді проекту (окремим її членам) і контроль їх виконання;

вимога від команди проекту виконання своїх рольових функцій;

підтвердження або відхилення звітів про фактичні витрати виконавців проекту;

обгрунтування необхідності і запит куратору проекту   на виділення додаткових ресурсів на проект;

звернення до куратора за підтримкою в разі потреби.

архітектор системи- проектна роль   посадової особи, яка відповідає за предметну область проекту. архітектор   системи підпорядковується безпосередньо керівнику проекту.

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

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

Основні функції:

визначення складу, тривалості і технології виконання робіт з розробки та впровадження інформаційної системи;

визначення ресурсів, які необхідні для розробки і впровадження ІС в рамках, заданих умовами проекту;

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

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

організація підготовки, погодження та затвердження всієї технічної документації, необхідної для створення ІС в рамках проекту;

планування та узгодження фактичних трудовитрат фахівців при виконанні проекту;

формування та надання керівнику проекту необхідної звітності;

аналіз ходу виконання і проміжних результатів створення ІС;

організація, проведення та документування процедур передачі замовнику розробленої ІС.

Основні повноваження:

участь в календарному плануванні робіт зі створення ІС;

призначення завдань робочим групам проекту і контроль їх виконання;

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

обгрунтування необхідності і запит керівнику проекту на виділення додаткових ресурсів на проект.

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

Основні функції:

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

ведення протоколів нарад;

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

Основні повноваження:

передача і отримання від учасників проекту необхідної документації по проекту;

контроль дотримання учасниками проекту встановленої системи документообігу;

вимога від конкретних виконавців за проектом оперативної інформації і звітів про хід робіт за проектом.

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

які цілі стоять перед співробітником, призначеним на цю роль;

кому підпорядковується співробітник, призначений на ту чи іншу роль;

які його функції, обов'язки, повноваження.

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

Таблиця 6.3. Вплив факторів зовнішнього середовища на планування команди проекту
Фактори зовнішнього середовища	Вплив на визначення ролей команди і відповідальності
організаційні	Взаємовідносини організацій або відділів, що беруть участь в проекті, механізми взаємодії між ними
Технічні	Навички та спеціальності, необхідні для виконання проекту, необхідність забезпечення координації між мовами програмного забезпечення, Наявність специфічних складнощів при переході від однієї фази життєвого циклу до іншої
міжособистісні	Офіційні і неофіційні відносини між потенційними членами команди проекту, їх посадові обов'язки. Культурні або мовні відмінності між членами команди, які можуть вплинути на їх робочі взаємини
політичні	Цілі та інтереси потенційних членів команди проекту, люди (або групи людей), які мають неформальний вплив в областях, які є важливими для проекту, існування неформальних зв'язків між потенційними учасниками проекту

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

Для забезпечення аналізу сукупностей навичок компоненти групуються в чотири категорії: технічні навички, адміністративні, навички міжособистісного спілкування, стратегічні навички. Для кожного навику відзначаються рейтинг   критичності і рейтинг   здібностей [ 12 ]. Для оцінки рейтингу прийнято використовувати 4-бальну шкалу (див. табл. 6.5).

Таблиця 6.4. Реєстр навичок   для команди виконавців проекту
Технічні навики Уміння управляти проектом і його технологією Надання допомоги у вирішенні проблем проекту Взаємодія з технічним персоналом Участь в досягненні компромісів розуміння тенденцій Розуміння основних завдань маркетингу Наявність навичок системного аналізу	Навички міжособистісного спілкування і лідерства Надання допомоги у вирішенні проблем Побудова багатофункціональної команди визначення цілей Отримання підтримки вищого керівництва Мотивація членів команди управління конфліктами
адміністративні навички Залучення унікальних фахівців Навички ефективного спілкування уміння делегувати повноваження Ведення переговорів з метою забезпечення ресурсами календарне планування Розуміння політик і робочих процедур Співпраця з іншими проектними командами	стратегічні навички Стратегічне планування Прийняття стратегічних рішень Уміння працювати в умовах ризику уміння лідирувати

реєстри навичок

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

приклад розробкиреєстру навичок

нижче ( табл. 6.5, табл. 6.6) Виділені категорії навичок для консультантів та менеджерів проектів: технічні, адміністративні, навички міжособистісного спілкування, стратегічні навички. Для кожного консультанта (як при прийомі на роботу, так і при зарахуванні в команду проекту) необхідно проводити оцінку навичок за шкалою 1-4 ( "погано", "задовільно", "добре", "відмінно" відповідно)

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

Налбандян Г.Г., Кушніренко Є.Б.    Факультет менеджменту Фінансового університету при Уряді РФ, магістерська програма «Управлінський консалтинг»
   Науковий керівник - к.е.н., доцент, доцент кафедри «Стратегічний і антикризовий менеджмент» Н.В.Ліндер
Стратегії бізнесу, №4 за 2014 рік

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

Проекти вимагають участі багатьох людей, але як уникнути ситуації, коли люди борються проти один одного при здійсненні певного завдання. Настільки ж складним є ситуація, коли ніхто не бере на себе відповідальність і не приймає рішення. Як люди повинні розуміти рівень власної відповідальності? До кого можна звернутися у разі виникнення питання? Хто повинен бути проінформований під час здійснення завдання або процесу? Застосування моделі RACI може допомогти відповісти на всі ці питання.

Матриця RACI являє собою простий інструмент, який використовується для визначення ролей і обов'язків та уникнення плутанини при виконанні завдань або процесів. Використовується при управління проектами і для показу обов'язків в станах "AS-IS" і "TO-BE".

Основна мета статті - дослідження методики RACI і її використання при управлінської діяльності.

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

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

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

Таблиця 1.   Резюме: Критичні питання моделі

Вказівки до побудови матриці

Готуючись до побудови матриці, необхідно знати «філософію» нової компанії при розподілі ролей і обов'язків. Заохочення роботи в команді можна назвати запорукою успішного просування проекту, при цьому 100% -ва акуратність часто не потрібно. також важливим моментом   буде виняток ланцюжка «перевіряються - перевіряючі - Перевіряються», що свідчить про подвійній системі звітності, яка призводить до плутанини і гальмування робочого процесу. Слід передбачити процес таким чином, щоб стверджувати (Accountable) і Відповідальна (Responsible) особи перебували якомога ближче до функціонального і наукомістких підрозділам. При цьому необхідно дотримуватися, щоб утверджує залишався єдиним на кожен підрозділ. Тісна взаємодія між компетентними органами влади і затверджується особою вважається хорошим прикладом внутрішньогрупового сприяння. Однак кількість Консультантів (Consultant) і інформує осіб (Informs) також має бути зведено до мінімуму. На завершення підготовчого процесу все ролі і повноваження повинні бути офіційно закріплені і підтверджуватися відповідною документацією.

Таблиця 2.   Умовні позначення матриці відповідальності - RACI

"R" Виконавець (Responsible)	Лежить відповідальність за виконання поставленого завдання. На кожну задачу повинно припадати не менше одного Виконавця. Ступінь відповідальності розподіляється стверджує
"A" утверджує (Accountable)	Перед ним проводиться звіт в отриманому результаті, є повноваження, як приймати, так і відкидати пропозиції, накладати на них вето. На кожен проект виділяється не більше одного стверджувати
"З" Консультант (Consulted)	Консультація і узгодження прийнятих рішень. Характеризується двостороннім зв'язком між підрозділами
"I" Інформіруемий (Informed)	Надходить кінцева інформація про виконану роботу. Характеризується одностороннім зв'язком

Матриця відповідальності вибудовується в шість етапів:

1. Проведення вступних зустрічей для інформування ключового менеджменту щодо цілей і вимог до процесу.
2. Лист прийняття рішень і функціональних обов'язків розроблені, проаналізовані і об'єднані в список основних функцій.
3. Семінари з розподілу обов'язків (Workshops) проводяться, щоб узгодити функції і наказати коди, що дозволяють описувати тип участі кожного, а також його роль щодо кожного процесу. Результатом стає побудова матриці відповідальності.
4. Матриці відповідальності документовані і повинні бути доставлені кожному учаснику процесу і взаємодіє з ними організаціям.
5. Комунікації і затвердження нових ролей повинні бути розроблені і затверджені шляхом нарад за участю всіх задіяних осіб і департаментів.
6. Наступні зустрічі організовуються для періодичного контролю, заохочення їх діяльності і щоб упевнитися, що учасники дотримуються всіх встановлених раніше правил.

Основними принципами прийняття рішень за допомогою RACI є:

1. Уникнення очевидних подій, наприклад "бути присутнім на засіданнях".
2. Кожна дія або рішення повинно починатися з доброго дієслова дії. Приклади: працювати, затвердити, підготувати, розвивати, перевірити і т. Д.
3. Коли дія дієслова має на увазі рішення (наприклад, оцінювати, контролювати), потрібно додати фразу, яка вказувала б на пріоритетний результат. Приклад: аналізувати дані, щоб знайти причину затримки доставки.
4. Дії та рішення повинні бути короткими, лаконічними і розробленими щодо певної ролі або функції, а не для конкретної людини.

Вертикальний аналіз (за функціональними ролями) дозволяє виявити відповідні проблеми: Якщо у Вас вийшло:

• багато R, в такому випадку потрібно задати собі питання, чи може певна людина бути відповідальним за таку кількість дій;
• немає порожніх клітинок - чи потрібно втягувати людей в таку кількість операцій?
• немає R або А - чи можна ліквідувати цю функціональну роль?
• Багато А - правильно чи розподіляються обов'язки? Чи можуть інші люди бути підзвітними у цих процесах?

При горизонтальному аналізі розглядаються дії Якщо у вас вийшло, що

• немає R, то тоді ніхто не несе відповідальності за процес, і він не буде виконаний;
• багато А - буде плутанина, тому що будь-який утверджує має своє бачення, як має бути здійснено дію;
• багато С - треба зрозуміти, чи потрібно в реальності консультуватися з такою кількістю різними функціональними ролями;
• багато I - може бути ситуація, де визначені ролі. Правильне використання RACI допоможе досягти таких цілей, як:
  • підвищення продуктивності за рахунок чітко структурованої ієрархічної системи;
  • зниження виробничих помилок, таких, як виробництво шлюбу, за рахунок з'ясування потрібних технічних характеристик;
  • збільшення продуктивності шляхом усунення дублювання і пересортиці на виробництві;
  • модернізована організаційна структура без зайвих функціональних елементів;
  • поліпшення процесу планування в зв'язку з великим участю членів команди в результаті будівництва комунікаційних ліній (консультування та інформування).

Підводячи підсумок, варто зазначити, що матриця розподілу відповідальності є важливим елементом успішного планування робочого процесу. В ході її грамотного використовуватися повинна підвищитися продуктивність на проекті, що досягається за рахунок наявності стверджує. При вмілому побудові робочого процесу сформується сильна команда, що складається з грамотних і натренованих гравців, здатних пропонувати нестандартні підходи до прийняття рішень. Як результат можна буде вибудувати більш продуктивну систему комунікацій між усіма учасниками завдяки розробці інтерфейсу зв'язку (Консультант і Інформоване).

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

1. Андерсен Б. Бізнес-процеси. Інструменти вдосконалення. - М .: РІА «Стандарти та якість», 2014.

2. Демінг В. Едвардс. Вихід з кризи. - Твер: Альба 2009.

3. Дрожжин В. Реінжиніринг бізнес-процесів в компанії // Ваш Банк '. Економіст. - 2012. № 2.

4. Друкер П.Ф. Практика менеджменту: Пер. з англ. - М .: Изд. будинок «Вільямс», 2011.

5. Єфремов В.С. Організації, бізнес-системи і стратегічне планування // Менеджмент в Росії і за кордоном. - 2013. - № 2.

6. Кальянов Г.Н. Теорія і практика реорганізації бізнес-процесів. Серія «Реінжиніринг бізнес-процесу». - М .: Сінтег, 2012.