Передача задач и полномочий лицу которое принимает на себя ответственность за их выполнение: НОУ ИНТУИТ | Лекция | Управление персоналом на предприятиях и в организациях

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

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

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

Делегирование полномочий преследует следующие основные цели:

-освобождение времени руководства для решения более важных задач;

-повышение мотивации персонала;

-повышение доверия в рабочем коллективе;

-проверка сотрудников на исполнительность

Ответственность не может быть делегирована.

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

  Концепции делегирования полномочий.

Две концепции процесса передачи полномочий (рис. 2.2.7.1):

1.    Классическая концепция — полномочия передаются от высших к низшим уровням организации.

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

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

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

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

Преодоление препятствий к эффективному делегированию:

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

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

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

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

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

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

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

Чем больше зависимость от другого лица, тем больше власть данного лица.

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

Делегирование полномочий

 

 

ВЫВОДЫ

 

В процессе написания курсовой работы были проанализированы литературные источники по вопросам делегирования полномочий руководителями. Было выяснено, что концепции соучастия в управлении и самоуправления появились более 30-ти лет назад. Вопрос делегирования руководителем полномочий изучали многие зарубежные и отечественные ученые, такие как Мескон М. Х., Альберт М., Хедоури Ф., Кунц Г. и Доннел С., Веснин В.Р., Герчикова И.Н. и другие.

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

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

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

Были также выявлены основные принципы делегирования полномочий. К ним относятся:

­       принцип делегирования на основе ожидаемых результатов;

­       принцип функциональной дефиниции;

­       скалярный принцип;

­       принцип уровня полномочий;

­       принцип единоначалия;

­       принцип безусловной ответственности;

­       принцип соответствия полномочий и ответственности.

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

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

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

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

 

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

 

1.      Веснин В.Р. Менеджмент: Учебник для студ.вузов. – М.: Элит-2000, 2003. – 546 с.

2.      Виханский О.С., Наумов А.И. Менеджмент: Учебник. – 3-е изд. – М.: Гардарики, 2002. – 528 с.

3.      Вудкок М., Френсис Д. Раскрепощенный менеджер (для руководителя-практика). – М.: Дело, 1997. – 320 с.

4.      Герчикова И.Н. Менеджмент: Учебник. – 4-е изд., перераб. и доп. – М.: ЮНИТИ-ДАНА, 2005. – 511 с.

5.      Мескон М., Альберт М., Хедоури Ф. Основы менеджмента: Пер. с англ. — М.: Дело, 2000. – 704 с.

6.      Мильнер Б. З. Теория организации [Текст] : учебник / Б. З. Мильнер. 2-е изд. перераб. и доп. М. : ИНФРА-М, 2002. 480 с.

7.      Старобинский Э. Передача полномочий – один из важнейших принципов менеджмента. //Управление персоналом, 2000 – №4. – с. 50-53.

8.      Грамотное делегирование — основа эффективной работы менеджера. [Електронний ресурс] // Режим доступу: http://psy.rin.ru/cgi-bin/article.pl?id=2050

9.      Соотношение централизации и децентрализации в структуре органов управления организацией. [Електронний ресурс] // Режим доступу: http://www.managment.aaanet.ru/osnovi/28.php

10. Централизация и децентрализация. [Електронний ресурс] // Режим доступу: http://bbest.ru/razryprresh/kadrresh/osnprinyprper/cenidecen/

 

 

Матрица RACI | Понимание матрицы распределения ответственности

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

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

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

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

 

Содержание

• Что такое диаграмма RACI?
• Определения RACI
• Создание модели RACI
• Внедрение RACI
• Преимущества RACI
• Ограничения RACI
• Программное обеспечение для управления проектами RACI
• 3 видео RACI, которые нужно посмотреть

Что такое диаграмма RACI?

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

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

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

Вернуться к началу

Определения RACI

Аббревиатура RACI означает различные типы ответственности: ответственный, подотчетный, консультируемый и информированный. В матрице RACI инициалы R, A, C и I назначаются рядом с человеком или должностью с каждым уровнем ответственности за каждую задачу или результат. В RACI люди будут играть разные роли в зависимости от задачи или результата, но не нескольких ролей.

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

Ответственный

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

Недостаток: RACI не отличает основного «исполнителя» от другого члена команды, участвующего в выполнении задачи.

Подотчетный

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

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

Консультации

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

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

Информированные

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

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

Предлагаемые книги

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

В начало

Создание модели RACI

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

1. Определите список ключевых действий и результатов

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

2. Определите, кто необходим для участия в проекте или инициативе

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

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

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

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

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

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

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

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

4. Проведение обзорных сессий с ключевыми членами команды для согласования

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

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

Что делать, если проект уже запущен?

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

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

Вернуться к началу

Внедрение RACI

Одна только электронная почта не приведет к эффективному внедрению RACI. Этот ключевой документ следует рассмотреть во время встречи с участием всех участников и заинтересованных сторон — в идеале во время стартовой встречи проекта. Сделайте это стандартной частью стартовой встречи вашего проекта.

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

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

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

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

Вернуться к началу

Преимущества RACI

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

Подробный план проекта и диаграмма Ганта

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

Структура руководящего органа

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

Полномочия подписи документации и действий (подтверждение)

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

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

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

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

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

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

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

Вернуться к началу

Ограничения RACI

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

Ограничения ролей

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

Еще одним пробелом в RACI является определение того, кто несет ответственность за проверяющую и подписывающую стороны. В этом случае вам следует рассмотреть матрицу обязанностей RACI-VS, поскольку проверяющая и подписывающая сторона могут не быть той же стороной, что и подотчетное лицо. Кроме того, RACIQ рассматривает ответственную сторону за качество, а RACIO также включает O для исключения из цикла, поскольку не у всех есть ответственная роль для каждой задачи. Те, кто назначен вне цикла, могут помочь управлять там, где роли не нужны, что поддерживает способность команды управлять своими возможностями. Когда все вовлечены во все, это может перегрузить команду и отвлечь ее от их реальной работы и вспомогательных задач.

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

Сведения о задаче

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

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

Не соответствует гибкому мышлению

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

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

Вернуться к началу

Инструменты управления проектами RACI Matrix

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

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

Вернуться к началу

Образцы диаграмм RACI

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

Хорошие шаблоны и образцы также можно найти на веб-сайте Project Management Institute.

Образец 1: Цветной код RACI с использованием только заголовков.

Образец 2: RACI с использованием имен и комментариев для дополнительной информации

Образец 3: Сложный RACI для Agile или Hybrid (ориентированный на команды) с комментариями и ссылками на определения

3 видео RACI, которые вам нужно посмотреть

Эти первые два видео содержат краткий фрагмент того, как RACI может работать на вас. Ищете более подробное объяснение? Смотрите видео три.

Видео 1: Основы RACI

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

Видео 2: Как составить собственную диаграмму RACI

Создайте диаграмму RACI всего за 11 минут:

Видео 3: Как RACI поможет вам управлять

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

Резюме матрицы RACI

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

Роли и обязанности в управлении изменениями — BMC Software

Блог по управлению услугами

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

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

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

Мы рассмотрим:

• Менеджер по изменениям
• Консультативный совет по изменениям (CAB)
• Emergency CAB
• Владелец процесса изменений
• Группы управления изменениями

Менеджер по изменениям

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

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

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

Консультативный совет по изменениям (CAB)

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

Вместе CAB отвечает за следующие виды деятельности:

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

Консультативный совет по экстренным изменениям (ECAB)

ECAB — это меньший по размеру орган в рамках CAB, специально занимающийся экстренными изменениями. (Экстренные изменения — это один из трех типов изменений в соответствии с ITIL.) Когда поступает запрос на экстренное изменение, менеджер по изменениям должен провести тщательный анализ и оценку, прежде чем принять окончательное решение вместе с CAB.

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

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

Владелец процесса изменений

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

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

• Разработка процесса при поддержке менеджера по изменениям и CAB.
• Доведение руководящих принципов до соответствующих заинтересованных сторон.
• Содействие межведомственному сотрудничеству, необходимому для управления изменениями.
• Оценка и совершенствование процесса управления изменениями.
• Отчет о выполнении процесса перед CAB и менеджером по изменениям.
• Инициирование усовершенствований процесса.

Группа управления изменениями

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

Отдельные группы по управлению изменениями могут состоять из трех ролей:

• Инициатор изменений. Лицо, ответственное за инициирование, подготовку и отправку запроса на изменение. Этот человек может поддерживать сбор необходимой бизнес-информации и взаимодействие с заинтересованными сторонами до того, как запрос на изменение будет назначен тестировщику изменений. Кроме того, запросчик изменений также работает с командой управления изменениями, чтобы поддержать оценку воздействия, собирая данные и общаясь с другими заинтересованными сторонами.
• Сменить владельца/правопреемника/исполнителя. Лицо, считающееся владельцем CR на протяжении всего жизненного цикла запроса. Тестировщик изменений также может взять на себя роль инициатора запроса на изменение и поддерживать процесс создания и отправки запроса на изменение. Владелец изменения следит за тем, чтобы были выполнены необходимые тесты, чтобы запрос на изменение соответствовал надлежащей срочности. Владелец изменения также должен документировать процесс на протяжении всего жизненного цикла запроса.
• Сменить утверждающего. Лицо, ответственное за первоначальное утверждение запроса на изменение перед его отправкой менеджеру по изменениям и CAB для принятия окончательного решения. Утверждающий изменения будет общаться с другими заинтересованными сторонами и поддерживать документацию до того, как запрос будет отправлен менеджеру изменений. Эта роль также является общей и может выполняться разными лицами на различных иерархических уровнях структуры управления изменениями. На каждом уровне утверждающий изменения гарантирует, что запрос на изменение достиг необходимого стандарта готовности, чтобы гарантировать принятие решения менеджером изменений и CAB.

Дополнительные ресурсы. ): Шаблон для реорганизации ИТ

Эти сообщения являются моими собственными и не обязательно отражают позицию, стратегию или мнение BMC.