책임 할당 매트릭스

Responsibility assignment matrix

책임 할당[1] 매트릭스(RAM)는 RACI 매트릭스[2](/reɪsi/) 또는 선형 책임[3] 차트(LRC)라고도 하며 프로젝트 또는 비즈니스 프로세스의 태스크 또는 성과물을 완료하기 위해 다양한 역할이 참여하는 것을 나타냅니다.RACI는 가장 일반적으로 사용되는 4가지 주요 책임(책임, 책임, 상담, 정보 제공)[4]에서 파생된 약어입니다.부문간 프로젝트 및 [5]프로세스에서 역할과 책임을 명확히 하고 정의하기 위해 사용됩니다.RACI 모델에는 몇 가지 대안이 있습니다.

RACI 모델의 주요 책임 역할

역할 구분

역할과 개별적으로 식별된 사람 사이에는 차이가 있습니다.역할은 관련된 일련의 작업을 기술하는 것이며, 여러 사람이 수행할 수 있으며, 한 사람이 여러 역할을 수행할 수 있습니다.예를 들어, 조직에는 프로젝트 매니저의 역할을 수행할 수 있는 사람이 10명 있습니다.종래 각 프로젝트에는 한 번에 1명밖에 없습니다.또한 프로젝트 매니저의 역할을 수행할 수 있는 사람도 비즈니스 분석가 및 테스터의 역할을 수행할 수 있습니다.

R = 담당자(권장자이기도 함
작업을 [6]완료하기 위해 작업을 수행하는 사람들입니다.관여 타입의 역할이 적어도1개 있습니다만, 그 외의 역할은 필요한 작업을 서포트하도록 위임할 수 있습니다(조연 역할에 참여하는 담당자를 개별적으로 특정하려면 아래의 RASCI도 참조).
A = 책임(승인자 또는 최종 승인 권한도 있음)
성과물 또는 작업의 정확하고 철저한 완료를 최종적으로 책임지는 사람, 작업의 전제 조건을 충족하는 사람,[6] 책임자에게 작업을 위임하는 사람.즉, 책임자는 책임자가 제공하는 작업을 승인(승인)해야 합니다.각 태스크 또는 [7]성과물에 대해 지정된 책임자는 하나만 있어야 합니다.
C = 컨설팅 완료(컨설턴트 또는 자문자일 수 있음)
의견을 구하고 있는 사람, 전형적으로 주제별 전문가, 쌍방향 [6]커뮤니케이션이 있는 사람.
I = 정보 제공자(정보 제공자)
작업 완료 시 또는 성과물에 대해서만 최신 정보를 유지하고 일방적인 [6]커뮤니케이션이 가능한 사용자.

대부분의 경우 태스크 또는 성과물에 대한 책임을 지는 역할도 해당 작업의 완료를 책임지는 역할(태스크 또는 성과물에 의해 매트릭스에 표시되지만 완료에 대해 책임을 지는 역할은 없습니다.즉, 암묵적인 것입니다.이 예외를 제외하고, 일반적으로 각 태스크의 프로젝트 또는 프로세스의 각 역할은 최대 1개의 참여 유형만 받는 것이 좋습니다.복수의 참가 타입이 표시되어 있는 경우, 이것은 일반적으로 참가가 아직 완전히 해결되지 않았음을 의미하며, 이는 각 태스크에 대한 각 역할의 참여를 명확히 하는 데 있어 이 기술의 가치를 저해할 수 있다.

시설에 사람을 배치하다

매트릭스는 일반적으로 (작업 분류 구조에서) 태스크의 수직축(왼쪽 열) 또는 성과물(제품 분류 구조에서)과 (조직도에서) 역할의 수평축(위쪽 열)으로 작성됩니다.

책임 할당(RACI) 매트릭스의 예
코드 이름. 프로젝트 스폰서 비즈니스 분석가 프로젝트 매니저 테크니컬 아키텍트 응용 프로그램 개발
스테이지 A 판매 관리
스테이지 B 작업 평가
스테이지 C 프로젝트 시작
(C04). 보안 거버넌스(초안) C C A I I
(C10). 기능요건 A R I C I
(C11). 사업승인기준 A R I C I
스테이지 D 설계 솔루션

유지보수 및 신뢰성 커뮤니티의 또 다른 예

유지보수 승무원 KPI RACI 차트
임무들 유지보수 감독자 유지보수 분석가 유지보수 플래너 유지보수 기술자 유지보수 지원 릴 스페셜리스트 CMMS 프로젝트 엔지니어
실패 데이터 입력 중 A C I R C C
워크오더완료 R C C C A I I
워크오더마감 C R C I I A
장애 데이터 입력 QA C R I C I C A
장애 보고서 분석 C C I C A R I
유지보수 전략 조정 C I I C A R R
새로운 전략의 실시 R I R C A I I

대체 수단

RACI 참가 유형에는 다음과 같은 여러 가지 대안이 있습니다.

RACI 역할 단축: 역할은 다음과 같습니다.

책임지는
작업을 완료하기 위해 작업이 이루어집니까?
어카운터블
딜러는 작업이 완료되었다고 판단되기 전에 작업 또는 성과물을 마지막으로 검토합니다.
상담했다
향후 프로젝트 작업에 어떤 영향을 미칠지 또는 성과물 자체에 대한 전문 지식을 바탕으로 의견을 제공합니다.
잘 아는
프로젝트 진행 시 모든 성과물에 대한 세부사항을 포함시키지 말고 계속 관련되어야 함

파리

이것은 책임 할당 매트릭스의 초기[8] 버전으로, 역할은 다음과 같이 정의됩니다.
참가자
어카운터블
검토 필요
입력 필수
사인오프 필요

PACSI

이는 문화의 협업적 특성으로 인해 한 사람/기능의 책임 하에 이루어지는 활동의 산출물을 여러 이해관계자가 검토하고 거부할 수 있는 조직에 매우 유용한 버전이다.
수행하다
액티비티를 실행하는 사람/기능.
어카운터블
최종적으로는 성과물 또는 작업의 정확하고 철저한 완료를 책임지는 사람/기능, 그리고 대부분의 경우 작업을 수행자에게 위임하는 사람.
통제
활동 결과를 검토하는 사람/기능.그들은 거부권을 가지고 있다; 그들의 조언은 구속력이 있다.
제안하다
인정받은 전문지식을 바탕으로 조언하기 위해 담당자/기능이 상담했다.그 조언은 구속력이 없다.
잘 아는
액티비티의 결과를 통지할 필요가 있는 사람/기능.

RASIC 또는 RASCI

이것은 표준 [10]RACI를 확장한[9] 것으로, RASCI라고 불리는 경우가 적습니다.이러한 확장 버전은 다음과 같습니다.
책임지는
승인자에 따라 작업이 수행되는지 확인하는 작업 담당자
지지하다
책임자에게 할당된 리소스입니다.작업에 대한 정보를 제공하는 컨설팅과 달리 지원은 작업을 완료하는 데 도움이 됩니다.

RASI

이것은 표준 RACI의 대체[11] 버전이며, 컨설팅 참여 전에 다음과 같이 대체되었습니다.
지지하다
구현에 있어 지원 역할을 하는 리소스.

RACI + F

이것은 표준 RACI의 확장 버전이며 추가 참여 유형:용이하게 한다.이 변형은 Christophe Le Coent에 의해 [12]2012년에 도입되었습니다.Coent는 퍼실리테이터 또는 코치의 역할은 신속한 변화를 위한 소프트웨어 개발 환경에서 중요하므로 [13]RAM에 명시적으로 포함시켜야 한다고 주장했습니다.신속한 변화를 위한 환경에서 RAM을 사용하는 것은 일부 실무자들은 신속한 변화를 위한 팀에서 일하는 모든 사람이 공동으로 책임지고 [14]책임져야 한다고 생각하기 때문에 논란이 많은 것으로 간주됩니다.
촉진
Scrum 프로젝트 중에 활동을 촉진합니다.

라시크

이것은 표준 RACI의 확장 버전이며 추가 참여 유형:
품질 리뷰
제품이 품질 요구 사항을 충족하는지 확인하는 사람들.

RACI-VS

이것은 표준 RACI의 확장[4] 버전이며, 다음 두 가지 추가 참여 유형이 있습니다.
검증자
제품이 제품 설명에 명시된 허용 기준을 충족하는지 여부를 확인하는 사람.
서명자
결정을 확인하고 제품 인도를 승인하는 사람.서명자가 그 성공에 대한 책임을 지는 당사자가 되어야 한다는 것은 이치에 맞는 것 같다.

카이로

이것은 표준 RACI의 확장[15] 버전입니다.RACIO라고도[16] 불리며, 1개의 추가 참가 타입이 있습니다.
Out of the Loop(또는 생략)
태스크의 일부가 아닌 개인 또는 그룹을 지정합니다.리소스가 참여하지 않도록 지정하는 것은 참여하는 사용자를 지정하는 것만큼 태스크를 완료하는 데 도움이 될 수 있습니다.

DACI

의사결정을 일원화하고 토론을 [17]재개할 수 있는 사용자를 명확히 하기 위해 사용된 또 다른 버전입니다.
드라이버
차를 운전하는 사람과 같은 전체 프로젝트의 단일 운전자.
승인자
대부분의 프로젝트 결정을 내리고 실패 시 책임을 지는 1명 이상의 승인자.
기부자
생산물을 책임지고 쌍방향 커뮤니케이션을 하는 일벌이다.
잘 아는
프로젝트의 영향을 받아 상태를 제공하고 의사결정을 통보받으며 일방적인 커뮤니케이션이 이루어지는 사람.

고속

의사결정 역할을 명확히 하고 의사결정을 개선하기 위해 사용되는 또 다른 도구는 RAPID입니다.RAPID는 Bain & Company에 의해 작성되었으며 Bain & Company의 등록 상표입니다.
권고한다.
권장 역할은 일반적으로 결정 작업의 80%를 포함합니다.제안자는 관련 의견을 수집하고 행동 방침을 제안합니다.때로는 의사결정자의 선택이 최대한 명확하고 단순하며 시기적절하게 이루어질 수 있도록 장단점이 있는 대안 코스를 제안합니다.
동의하다
agree 역할은 권장 사항에 대한 정식 승인을 나타냅니다.'A'와 'R'은 서로 만족할 만한 제안을 도출하기 위해 협력해야 한다.그러나 모든 의사결정에 동의하는 역할이 필요한 것은 아닙니다.이는 일반적으로 어떤 형태로든 규제 또는 컴플라이언스의 승인을 필요로 하는 상황을 위해 예약되어 있기 때문입니다.
수행하다
perform 역할은 결정이 내려진 후 실행 또는 구현에 대한 책임자를 정의합니다.베스트 프랙티스 기업은 일반적으로 P를 정의하고 프로세스 초기에 P로부터 의견을 수집합니다.
입력
입력 역할은 추천인과 결정자가 올바른 결정을 내리기 위해 모든 관련 사실을 평가할 수 있도록 관련 정보와 사실을 제공한다.하지만 '나' 역할은 엄격히 권고 사항입니다.추천자는 모든 의견을 고려해야 하지만 최종 추천서에 모든 관점을 반영할 필요는 없습니다.
결정하다
결정 역할은 최종 결정을 내리고, 그룹을 행동에 옮기고, 그 결정이 확실히 이행될 수 있도록 최종적으로 책임을 지는 한 명의 개인에게 있습니다.

래티

조직 설계 또는 역할 분석에 사용되는 다른 도구입니다.
책임.
작업 완료 여부를 확인하는 담당자를 특정합니다.
권한
작업에 대한 최종 결정권을 가진 사람을 특정합니다.
작업
실제로 누가 그 일을 하고 있는지를 특정한다.
지지하다
작업에 대한 지원 담당자를 특정합니다.
잘 아는
작업이 완료(또는 시작될)되었다는 통지를 받은 사용자를 식별합니다.

DRASCI

세 명의 화이트홀 이론가(케인, 잭슨, 길버트)가 개발한 RASCI의 변형입니다.이 스킴은 매트릭스 관리 환경에서의 사용에 적합하며 드라이버의 역할이 추가되고 지원의 정의가 좁아진다는 점에서 RASCI와 다를 뿐입니다.
드라이버
목표의 전체적인 달성을 책임지는 개인 또는 당사자의 중요한 목표에 따라 지원 담보물을 작성하거나 납기를 설정함으로써 업무를 수행하는 책임자를 지원하는 개인 또는 당사자.드라이버와 서포트의 구별은, 전자가 책임 있는 사람을 대신해 업무의 파라메타를 강화해 명확하게 하는 것에 있는 반면, 후자는 주어진 목표 달성을 돕는 사람을 말한다.

PDQA

모델 기반 프로젝트 관리를 위해 U Tokyo 및 MIT에서 개발된 버전입니다.PDQA 역할 세트는 팀의 능력에 대한 요구에 대응합니다.역할에는 범위 작업, 조정으로서의 의존관계 처리, 프로젝트 조직 전체의 오류 검출 및 결정을 통한 예외 처리 등이 포함됩니다.PDQA는 에이전트 기반 모델링에서 사용되며 프로젝트의 [18]팀별로 이러한 기능의 공급을 시뮬레이션합니다.
기본적인
범위를 완성하기 위한 능력 범위 내에서 스킬 기반 작업을 제공하고 조정을 통해 의존 관계를 관리합니다.
결정
재작업으로 이어지는 허용 범위 및 예외 처리 결정을 포함하여 모든 결정을 처리합니다(공칭 범위를 생성하지 않음).
퀄리티
품질 저하를 검출하기 위해 진행 중인 범위를 확인하고 의사결정자에게 에스컬레이션합니다(일반적인 명목상의 범위는 아닙니다).
돕다
프라이머리에 대한 지원을 위해 범위를 완료할 수 있는 능력을 갖춘 스킬 기반 작업을 제공합니다(조정으로 의존관계를 관리하지 않습니다).

DCI

조직의 설계 또는 역할 분석에 사용되는 의사결정 카테고리의 최소 세트.
의사결정자
의사결정을 내리고 그것이 비즈니스에 미치는 영향을 책임지는 개인.
상담했다
개인은 기능상의 전문지식과 경험에 근거한 가이던스를 제공하고 문제를 강조하며 의사결정자를 지원하기 위한 대안을 제시할 책임이 있습니다.
잘 아는
영향을 받는 이해관계자는 결정이 내려진 후, 그리고 결정의 실행을 지원할 필요가 있는 사람에게 통지됩니다.

라스시오

거버넌스, 리스크, 컴플라이언스(GRC) 및 아웃소싱 문제에 대해 작업할 때 사용하는 방법:

책임지는
어카운터블
지지하다
컨설팅
실행
서비스 수준 계약에 따라 활동을 수행하도록 계약된 제삼자
통지하다
개요
리스크 소유자, 정책 소유자 등의 주요 GRC 역할 - 책임성이 위임되지만 책임성이 모두 일치하는지 여부를 감독하는 역할이 필요합니다.

바리에이션

또한 RACI 참여 유형의 의미에는 다음과 같은 여러 가지 차이점이 있습니다.

RACI(대체 방식)

덜 널리 발표되었지만 일부 실무자와 프로세스 매핑 소프트웨어에 의해 사용되는 대체 코딩이 있습니다. 이 소프트웨어는 원래 체계의 R 및 A 코드의 적용을 수정합니다.전체적인 방법론은 동일하지만, 이 대안은 관리 전문가에 의해 이해될 수 있지만 항상 다른 사람에 의해 명확하게 구별되는 것은 아닌, 책임 있는 용어의 혼동을 방지합니다.
책임지는
작업 수행을 책임지는 다음과 같습니다.각 태스크에 대해 이 과제를 가진 사람이 정확히 한 명 있어야 합니다.
지원
작업 완료를 지원하는 사람
상담했다
의견을 구하고 쌍방향 커뮤니케이션이 가능한 사람들.
잘 아는
진보에 대한 최신 정보를 유지하고 단방향 커뮤니케이션이 있는 사람들.

ARCI(결정)

이 대안은 누가 어떤 결정을 내릴 권한을 가지고 있는지를 문서화하는 데만 초점을 맞추고 있습니다.이 기능은 모든 규모의 워크그룹에서 사용할 수 있습니다.
어카운터블
결정에 대한 답변을 승인할 권한이 있습니다.
책임지는
결정에 대한 답변을 제안할 책임이 있습니다.
상담했다
의견을 구하고 쌍방향 커뮤니케이션이 가능한 사람들.
잘 아는
결정 후 통보받은 사람 및 일방적인 커뮤니케이션이 있는 사람.

레퍼런스

  1. ^ "9.1.2.1 Organization Charts and Position Descriptions". A Guide to the Project Management Body of Knowledge (PMBOK Guide) (5th ed.). Project Management Institute. 2013. p. 262. ISBN 978-1-935589-67-9.
  2. ^ Jacka, Mike; Keller, Paulette (2009). Business Process Mapping: Improving Customer Satisfaction. John Wiley and Sons. p. 257. ISBN 978-0-470-44458-0.
  3. ^ Cleland, David; Ireland, Lewis (2006). Project management: strategic design and implementation. McGraw-Hill Professional. p. 234. ISBN 0-07-147160-X.
  4. ^ a b Blokdijk, Gerard (2008). The Service Level Agreement SLA Guide - SLA Book, Templates for Service Level Management and Service Level Agreement Forms. Fast and Easy Way to Write Your SLA. Lulu. p. 81. ISBN 978-1-921523-62-5.
  5. ^ Brennan, Kevin (2009). A Guide to the Business Analysis Body of Knowledge (BABOK Guide). International Institute of Business Analysis. p. 29. ISBN 978-0-9811292-1-1.
  6. ^ a b c d Smith Michael, Erwin James: RACI(Role & Responsibility Charting), 프로젝트 관리 포럼, 2005, 페이지[dead link] 5
  7. ^ Margaria Tiziana: 형식적 방법, 검증 및 검증의 활용: 제4회 출원 절차 활용에 관한 국제 심포지엄, Part 1, Springer, 2010, 페이지 492
  8. ^ A Guide to the Project Management Body of Knowledge. Project Management Institute. 2000. p. 111. ISBN 1-880410-22-2.
  9. ^ Hightower, Rose (2008). Internal controls policies and procedures. John Wiley & Sons. p. 83. ISBN 978-0-470-28717-0.
  10. ^ Baker, Dean (2009). Multi-Company Project Management: Maximizing Business Results Through Strategic Collaboration. J Ross. p. 58. ISBN 978-1-60427-035-8.
  11. ^ Mikes, Joe; Denton, Tara (2011). Training Speeds Continuous Improvement. Life Cycle Engineering.
  12. ^ https://web.archive.org/web/20171016061719/https://www.scrumalliance.org/community/articles/2012/june/the-raci-f-matrix
  13. ^ https://web.archive.org/web/20171016061719/https://www.scrumalliance.org/community/articles/2012/june/the-raci-f-matrix
  14. ^ "RACI Matrix Definition and Example How to".
  15. ^ Bolman, Lee (2008). Reframing organizations: artistry, choice, and leadership. John Wiley & Sons. p. 112. ISBN 978-0-7879-8799-2.
  16. ^ Dickstein, Dennis (2008). No Excuses: A Business Process Approach to Managing Operational Risk. John Wiley & Sons. ISBN 978-0-470-48110-3.
  17. ^ Kendrick, Tom (2006). Results without authority: controlling a project when the team doesn't report to you. AMACOM Books, division of the American Management Association. p. 106. ISBN 0-8144-7343-1.
  18. ^ Moser, B. R.; Wood, R. T. (2015). "Design of Complex Programs as Sociotechnical Systems". Concurrent Engineering in the 21st Century. Springer: 197–220.

외부 링크