所謂實施了ITIL V3其實不是一個規範的說法，因爲ITIL V3也是一個框架庫，用戶完全可以選擇其中某一部分有用的來實施，可以採納並修改，這屬於局部實施，還有一種更常見的，就是可以選出一些流程組和職能組，結合一些ITIL V3概念形成一套貼合自己的管理模式，這屬於項目制實施，
CIO時代網記者：各位網友大家好，歡迎收看CIO時代網推出的信息化百家講壇欄目。我是記者李軍俠，本期欄目我們很榮幸的邀請到了上海翰緯信息管理諮詢有限公司高級講師劉頲劉老師，劉老師同時也是翰緯諮詢高級諮詢顧問及培訓部交付經理，在IT服務管理領域具有豐富的理論和實踐經驗。那麼我們本期的話題是關於IT服務管理中最佳實踐框架ITIL V3的落地與實施。那麼首先有請劉老師做一下簡單的自我介紹。
我個人的經歷比較複雜，在IT這個行業內經過了十多年的歷練，其中工作包括IT運維工作、開發工作、管理工作甚至有許多工作是與業務相關。那麼最近幾年來我主要的精力是放在ITSM這個專業領域內，包括培訓工作、項目諮詢以及研究工作。最近比較忙，重要的工作是參加撰寫中國IT服務管理標準，以及即將推出的《IT服務指南二》，這也是行業內大家比較矚目的一套出版物，我也是主編之一，最近當然有一些項目也在做，包括上海理想、首信、阿里巴巴等項目中也不同程度地擔當一些重要的諮詢工作，另外課程排的比較緊，這就是我的一些個人經歷。
CIO時代網記者： 作爲業內人士都知道，ITIL V3 於 2007 年 5 月 31 日 全球首發，將生命週期原理貫穿於實踐，它把IT上升到企業戰略資產管理的高度，充分展示了IT服務的價值。 劉老師作爲IT服務管理領域的專家，對於ITIL V3應該有比較深刻的理解，可否給我們做一些講解？
劉頲：作爲專家我覺得有些過了，在業內很少有人自稱爲專家的，大家都本着解決實際問題的心態去投入到這個領域，但是對於ITIL V3的這個領域我是很樂意來分享的，因爲翰緯是最早將ITIL V3本地化的機構之一，當時我也作爲編寫者之一，我們最早把它引入到中國來本土化。對於ITIL儘管才推出第三個版本，但它的歷史是非常悠久了， ITIL的全稱是IT Infrastructure Library，意爲IT基礎架構庫，我們一般稱之爲IT服務的最佳實踐框架，因爲它來自於最佳實踐，而且也跟一個歷史事件有關係。在八十年代初期的時候， ITIL V1版本便推出來了，在ITIL V1推出來的時候，有三四十本書，我能找到的是三十七本書，那麼這裏面描述了很多最佳實踐，最早推出來的是職能化管理概念，對於當時來說，進步意義還是很大的，在99年前後，英國商務部OGC正式的把它買過來，開發出了ITIL V2，就是我們很經典的十個流程加一個職能，那麼不管ITIL 自身承不承認，他把ITIL 開發成爲十個流程，以至於我們在內的不少業內人士都習慣性地把實施了哪些流程來體現是否實施了ITIL，這是V2的一個經典之作，發展到現在也有十年了。
ITIL V3的發展我曾經在不同場合表達過我的看法，我認爲最大的改變在於三方面：
第一個就像你剛纔也提到的引入了服務生命週期的概念，原來 ITIL V2是一種草根文化，是自下而上的發佈，另外是階段性的，好比是隻列出了人生中的小學和大學，但是對於人生前乃至胎教，人生後包括墓誌銘其實都應該納入到生命週期裏來，ITIL V3將服務全生命週期引入進來後，把服務戰略直到服務改進都納入體系，這無疑是一個非常有意義的事情，使得IT服務管理更體系化了，這點改變是非常大的，非常值得我們去探索的。
第二方面是它更加強調價值觀，它使得我們IT服務更加以價值爲中心，每一個章節，每一個細節，它甚至將很多流程都淡化了，他講了很多概念化的東西，而流程卻減少了篇幅，這對我們後面具體實施上其實也帶來了一些挑戰。
第三個改變是在流程上做了很多細化拓展的工作，這點我覺得也是非常優秀的。那麼這是我對ITIL V3正面的三個看法。
CIO時代網記者：ITIL V3是引入中國了，但是大家真正比較關心的還是ITIL V3從07年引入中國到目前兩年來實施狀況如何？在現實中是否真的是擲地有聲？
劉頲：像你這個問題，我幾乎每天都會遇到，剛纔我提到了我對ITIL V3有三個正面的看法，言下之意當然還有一些負面的看法，這個暫且不多提，不過有一點我想首先可以糾正一點，所謂實施了ITIL V3其實不是一個規範的說法，因爲ITIL V3也是一個框架庫，你完全可以選擇其中某一部分對你有用的來實施，你可以採納並修改，這屬於局部實施，還有一種更常見的，也是我個人經常實施的，就是你可以選出一些流程組和職能組，結合一些ITIL V3概念形成一套貼合自己的管理模式，這屬於項目制實施，還有一種實施就是完全按照ITIL的套路來梳理，我們姑且稱爲全面實施，這點實際上在全世界可以說是鳳毛麟角，其實也不存在，大部分企業都會根據自身的情況作相應的調整。所以說這點是首先需要明確的，到底什麼叫實施ITIL V3。那麼大家很關注的應該是嘗試做的事情，在業內我至少聽過兩家外資企業說他們實施了ITIL，其中一家在我實際的考察中發現，他們只不過是列出了很多流程經理的稱謂，但在全面建設上，實際上還只處於規劃階段，另外有一家企業不屑地說，ITIL V3是學習他們的，是採用了他們的實踐。這點我相信，因爲ITIL V3本來就採用了很多業內的最佳實踐。但這是否等同於我們所說的“實施”了ITIL V3呢？
提到ITIL 的實施，你首先要清楚ITIL V3本身是取決於最佳實踐的，它具有一些重疊性並不意外，另外OGC或者ITSMF他們把這些最佳實踐形成一個框架，理論化，畢竟現在才兩年時間，而ITIL V2十年了，但其實落地較多的還是我們常說的五加一，就是服務支持中的流程以及服務級別管理， 當然還有服務檯是和事件管理一起來做的，算在服務支持塊裏。你也不能說全部實施了ITIL V2，所以對於ITIL V3的實施，我只能說大家在探索中，並且在逐步實施中，並且我未來想要全面實施ITIL V3，全面符合ITIL V3，恐怕這種可能還是比較小的。這是我的一個基本的看法。
CIO時代網記者：聽您講了這麼多， ITIL V3實施起來其實不是那麼容易，感覺還是道路漫長的感覺，但是目前來說如果作爲企業的實踐者來說，最想要聽的還是具體實施的方法，劉老師在這方面能否給一些建議？
劉頲：這兩年我們與很多實踐者和探索者也在努力做很多事情，那麼我想在接下來的時間我們可以花點時間把ITIL V3整個生命週期中的每個模塊，到底我該怎麼做，或者說別人怎麼做，咱們倒是可以來探討一下，希望能夠給大家一些提示。
首先ITIL V3分爲五個模塊，就是大家所熟知的服務戰略，服務設計，服務轉換，服務運營和服務改進。那麼我曾經做過一個比喻，它好比裝修房子的一個過程。
服務戰略
那麼首先服務戰略這個模塊，這個模塊是大家爭議比較多的一塊，這個模塊的實施最首先感覺的一點就是比較難以把握，因爲我的結論是並不是一個企業沒有實施，而是往往實施之後的結論很簡單，比如說一個公司的這塊做的比較好，但是最後可能也只會歸納成爲一句話：某某企業有效利用自身某某資源與某某能力，將某某產品與某某服務轉換爲具有效果與保障的價值，傳遞給某某客戶，中間產生了很多utility，就是效果，有很多security，就是保障。客戶很滿意，投資方很賺錢，好像就結束了，這是這個部分的特點。但是實際上，這部分已經有很多成功案例，在ITIL V3以前就有了。我舉一個簡單的例子，比如移動公司，針對年輕人、老百姓和商務人士，根據各個羣體的移動使用業務，制定出動感地帶、神州行、商務通等不同的套餐。這個其實是一個非常有效的戰略之一，在ITIL V3的服務戰略的需求管理中，則可以體現爲PBA結合UP產生SLP。 這個模塊的實施是很模糊的，我的看法是：如果我們企業或者IT組織的相關管理者，能根據ITIL V3服務戰略中的指導方向，有效調配我們的資源與能力，識別服務資產的類別，瞭解產品組合的基本方法，最終，很重要的是，能將服務真正產品化，市場化，價值化，我認爲這就是實施了ITIL V3的服務戰略。這個模塊不同於另外一些以流程爲主的模塊，通篇幾乎就沒有明確的流程，所以這個部分成功實施不等於說我們做了什麼流程。好比我們看了德魯克的管理學，你說有沒有實施呢？我們實施了，可能體現在決策之中，我們的交付物將會是決策的結果，而並非流程手冊。所以說這塊的實施如果企業能夠根據ITIL V3的指導思想，能夠理解什麼是我的資源，什麼是我的能力，什麼是我的產品組合，什麼是我的市場需求，什麼是我的價值共產化，最重要的一點是你能不能產生一個服務產品化，我覺得如果能夠做的話就是在實施。（根據現有資源和自己的能力，組合產生有需求的產品）
服務設計
關於服務設計這個模塊，我們不會陌生，包括V2時期的服務級別管理、可用性管理、能力管理以及可持續性管理，這些流程雖然不陌生，但是除了服務級別管理外全面實施的本來就不多，原因是牽涉面較大，無法協調管理，但平時日常工作中，這些工作一點也沒有少做，重要的是沒有形成規範流程而已，這也和大部分ITIL工具只擅長工作流，不擅長價值判斷有很大關係。值得注意的是，這個部分加了三個流程，一個是服務目錄管理、一個是供應商管理，還有一個是安全管理。這都是很有價值，尤其是服務目錄管理，我們幾年前就開始在很多企業的服務級別管理當中去實施過，最近幾年隨着服務產品化的推出，我們的工作更多了，互聯網行業由於特殊性，在這方面走得比較早，有一些企業在我們帶動下，內部也逐步形成了服務目錄制定的熱潮，我一度把服務目錄和知識庫、配置管理數據庫稱爲三個最難逾越但最值得逾越的難關。服務目錄實施中最重要的是要理解一個淺顯的道理，就是能讓客戶看明白和用明白。除了互聯網企業，有些企業開始印刷了一些以服務爲導向Catalog，很好，雖然產品體系沒有建立，但是感覺對了，還有的企業做了很細緻的產品操作說明，這點要注意了，這可以作爲產品目錄的一部分，但是切忌只有自己能看懂。
供應商管理的落地不多，因爲機會不多，很多IT組織的採購工作會由一些採購部門進行，不過他們可能沒有意識到，ITIL V3很有可能涉及到的部門並非只是IT部門，這個以後還可以談。關於安全管理，其實從V1開始一直有，不過一直有些姥姥不疼舅舅不愛，我覺得重點在於這些內容更多是關注在一些政策上，而實際中的安全管理需要落地到技術纔有用。很多年前，我們慕名從國外花了一千多人民幣，買了本相關的書未來，一百多頁，看了半天，大家只得出一個結論：就是IT信息安全管理很重要。然後沒了，我們當即無語。其實服務設計這本書是我個人比較喜歡的書，除了一些流程的設計外，很多有用的模型如RACI（http://baike.baidu.com/view/2471567.html?wtp=tt）等等流程外的內容也很有用。我建議有了一定規模的IT組織好好學習這個部分，有些地方可以開始實施起來了。
服務轉換
服務轉換部分包含大家熟悉的配置與資產管理、發佈與部署管理以及變更管理，同時加了知識管理、評估、驗證與測試等一些流程。首先我們說說原來V2有的三個流程，發佈與變更我們很多時候是作爲一個項目來實施的，配置管理則一般基於建設CMDB作爲關鍵點，均是比較難實施的流程，重點在於它不僅僅只是設計流程那麼簡單，還需要最大限度考慮組織的組織架構以及組件架構，更難的是遵行與維護，我們幾度訪談以往的客戶，往往在後期不能加強管理，使得這些流程和模型變成雞肋，不管是V2還是V3，這都是我們要重點去關注的，我可以講一個案例，有個企業最初有四個小組，他們的小組長很願意實施變更管理，因爲老是變更有衝突，後來他們直接都擔任變更經理，有一位作爲主導者來召開CAB，變更經理們負責錄單和分配工作，按道理沒有問題。但幾個月後我們去回訪，發現裏面單子填寫得敷衍了事，服務檯也反映仍然有多次變更衝突事件。原因呢？其實這幾個組長很苦惱，因爲他們工作太忙，填單的事情太複雜。好吧，那麼就請個專職的變更經理，但煩事又來了，他們希望這位未來的變更經理，又要懂技術，又要懂流程，又要會溝通，又要能鐵面無私，技術還得不比他們差，結果每天做錄單的活……這個事情我估計我也不願意幹。其實變更經理真的要是多面手嗎？他其實重點在於流程的熟悉與KPI的熟悉，並且能有基本的IT知識，有主持CAB的能力是關鍵。在我們幫助下，他們逐步改變了招聘政策--案例是次要的，問題是，如果我們不回訪，誰會去逐步改進這個流程呢？所以這幾個流程實施還是很有挑戰的，這和V2還是V3的關係不是太大。不過另外幾個流程就是新增的流程，我很難回答大家有沒有實施它，因爲它本來就是從很多軟件開發環境中採納的最佳實踐，這個部分的落實關鍵點不是流程，而在於開發與運維的關係，現在IT服務管理中非常難的一個事情是，明明IT開發工作是服務交付的重要一環，但偏偏運維經理幾乎就無法調用開發人員的資源，並且開發人員長期以來對於什麼是故障，什麼是問題，什麼需要快速處理哪怕只是用應急措施，什麼需要根本解決也處於相對茫然。所以對於其它的大部分流程來說，難點其實就是在於組織間的整合，倒並非是流程的採納。
另外有一點很重要的是，知識系統管理，知識庫的建設是業內常討論的話題，知識系統管理的野心遠遠大於知識庫，它幾乎包含了ITIL V3的所有相關數據與信息乃至支持系統，但我們現實中實施更多的還是知識庫，知識庫的建設是個永恆的話題，我們這次就不多提。
運營管理
接下來就是原來實施得最多的運營管理，這個部分事件管理，服務檯，問題管理可以講是ITIL裏面的老兵，如果你瞭解過ITIL，你就不可能沒有聽說過它們，不過這次ITIL V3加了三個流程，一個是服務請求實施，一個是安全訪問，一個是事件管理，這個事件管理是event management，先談談最後的Event management，這個流程我們嘗試在一些企業實施過了，我們可以理解爲是故障，問題，變更前的一個哨兵，比如設定一些閾值，超過了某個閾值是記錄呢還是自動響應，還是說轉往故障管理流程。這個流程實施不難，很多企業自己都有，就是沒有規範化，對工具的依賴性很強，我也曾考慮過是否需要專門設定這樣的流程。安全訪問流程其實也被很多企業在技術上採納了，只是沒有規範起來，而服務請求實施就是把一些服務請求，如標準變更，密碼修改，諮詢，文檔要求等一些非故障類事情單獨設流程。有些企業也實施了，比如他們把該類請求轉到一個專門的部門，對於這個部門主要是考覈客戶滿意度，不着重考覈平均修復時間。其實這幾個新添的流程從很大意義上是考慮到了呼叫處理的多樣性，在以往我們實施的案例中，都或多或少涉及過。至於如今是否需要新設流程，我覺得要根據實際情況來分析。
服務改進
最後一個模塊是服務改進，和服務戰略有類似的地方，裏面更多的是方法論，一堆方法論足以讓你們看得頭暈。但是優化改進是很重要的，這個部分如何實施？我覺得當你打算進行優化的時候，就已經開始實施了，因爲你實施中可以根據ITIL提供的一些方法論和模型進行指導即可，中間的細節工作，如考覈，考評還是要根據實際情況來。對於服務改進，也是一個非流程的實施單元，而是個思想實施與參考實施的單元。
CIO時代網記者：劉老師不虧是ITIL V3實施的專家，給出這麼多的關於實施的真知灼見。假如實施一個系統的話，會考慮實施是否成功，那麼就ITIL V3實施的話怎麼樣纔算是成功了？這個有沒有一個可以藉以判斷的標準？
劉頲：首先ISO20000確實是itSMF與國際標準組織來評估IT組織IT服務管理水平的一種方法，不過，大家都知道在中國無論是企業還是個人，都很擅長應對“考試”，所以我們往往存在儘管ISO20000通過了卻未必意味着內部管理提升的現實。因而我們一般做項目的時候會根據實際情況來選擇對組織的“關鍵流程”進行細化處理，已達到效果。
至於說什麼是ITIL的成功案例，這個問題你會覺得很有趣，因爲我知道很多企業都會把他們實施過的案例都稱爲成功案例，比如有個着名的保險公司，曾經於五年前幾乎全面實施ITIL，被譽爲成功案例，但在一個月，我和他們的關鍵人聊起來，他們很痛苦的是，如果企業因爲工具等方面的原因，開始全面抵制ITIL，新的領導甚至提出了“趕走ITIL，還我實效”的口號，作爲最佳實踐的框架，被人稱爲不實際是很可悲的，但是這個現象也是廣泛的。你能說我會承認這是成功案例嗎？
重點在於，ITIL的實施不能完全是項目制的，而是長期要進行的，需要定期的優化，定期的改進。
所以你要問我心目中什麼是ITIL的成功案例？
我會說，首先跑起來了，在一定時期內能得到有效反饋，有專人，根據各種指標進行問題分析和優化改進，能逐步爲客戶、員工及相關利益者所接受，最終產生價值。
所以即便在翰緯，成功案例只是一個相對值，如果哪個企業由於主動或被動去放棄優化改進，我們都很難稱之爲成功案例。
當然在我心目中，我們和阿斯利康、阿里巴巴、浦發銀行、佛山電力、上海電信以及各地一些移動公司、地鐵公司等大概幾十個企業做的項目，個人還是比較滿意的，因爲我們形成了一種共同創造價值的文化，只要有這種文化，就意味着改進會不斷進行，這種持續改進則是我心目中的成功案例。
CIO時代網記者：剛劉老師提到了有很多案例是比較成功的，但是成功判斷也是有一定的，ITIL V3實施了，也成功運營了，但是能不夠給企業帶來預期的績效呢？運維績效評估也是我們比較關注的，績效評估是否也有一些具體的實施方法或者流程？
劉頲：你的意思我明白就是說你說你是一個成功的人士，爲了建設與改進一些流程和模型，我們確確實實地採用了許多評估方法。一般的評估方法是採用PPT結構，即Process流程，People人，Technology&Tools工具與技術的方面進行。
對於工具的評估，有很多方法，不過我們一般是把它作爲流程評估的一部分來進行。
對於流程的評估我們是比較熟悉的，一般採用的是將一些成熟的模型對應到一些定製化的問題上，而我們訪談的時候，也並非採用機械式的問答，而是採用開放式的問題，利用我們的經驗逐步將開放問題映射到既定問題上，然後做周密的差距分析，從科學的方法得出正確的結論。這種方法也是我們大多數諮詢項目與研究項目中的方法，我在授課時也偶爾會將一些自己在項目中的實例拿來幫助學員理解知識的實踐方法。
重點要談一談People這一塊，對於人員的評估，存在不少的挑戰，儘管有很多人力資源的管理方法論和模型，但是對於IT人員，尤其是IT服務人員的評估方法是很匱乏的。但是IT服務人員的價值急需得以體現，不然就會出現他做了一百件好事情沒有人說好，做錯一件事情天天有人追着跑，還有很多喫力不討好的事情。但是現在很多人是通過對部門的考覈或流程的考覈來考覈人，或者根據技術崗位來考覈，這不是很公平的，比如說，服務檯的人員考覈不應該專以技術來考覈，單純考覈客戶滿意度和平均修復時間也未必是最科學的。當然這有難度，第一難在服務的特質，二難在這類崗位本來就沒有標準規範。這點ITIL V3試圖做到，比如大家可以去細讀服務運營這本書裏面，除了服務檯，它加了三個職能，是技術管理，應用管理和運營管理，就提到了很多相關的Responsibility，但是即便如此，它沒有，也不大可能有去映射到具體崗位的評估。
不過現在還好，因爲在我們主編的中國IT服務管理標準中，特別提到了IT服務人員的崗位設定，如IT服務產品經理、IT服務銷售經理等以往大家一直在做，但很少定義的位置。
所以我們正在開發一套ITHRM的體系，不久就會和大家見面，爲此包括我在內的不少同事也正在一起開發IT服務人才培養方案，希望這些行爲都能給大家做績效評估提供一些有價值的方法。
CIO時代網記者：由於時間關係，我們只能講到這裏，但是關於ITIL V3實施我想劉老師是不是能夠提幾點最關鍵的建議？
劉頲：是啊，時間真快，不過和我平時的工作比，今天講的內容其實真不多，在有限的時間內，我能講的也就這些了，希望大家不要見怪。象李記者剛纔提到希望我能歸納幾條ITIL，尤其是ITIL V3實施的建議，我想，這樣一個高效運作的大機器，一定不會是幾條建議就能解決根本問題的，不過
我還是簡單說幾個我在實施項目中的基本原則吧。
1、步驟要對，我們一般採用意識運動、評估、訪談、差距分析、設定流程，設定指標、上工具、預實施等方法，切忌依賴工具，以爲一了百了。
2、不要盲目去對ITIL V3 做映射，但是要考慮ITIL V3的思想，建立屬於自己的服務生命週期。然後去用ITIL V3 框架提到的方法。
3、第三，還是那句話，工具，流程，人員都要考慮的同時，千萬也忘記優化改進。
很多企業ITIL實施最大的失敗處，很簡單，就是缺少一個Owner，沒有人專門對流程改進負責。這點無論是ITIL V2還是ITIL V3都通用。
最後，大家也可以看到，ITIL V3多了這麼多流程和思想，甚至很多組織還沒有實施過ITIL V2時代的最佳實踐。我建議採用quick win 方式。比如說服務檯的工作很多，但是實施的時候，考慮多方面因素，很多組織先落地之時，只是建立呼叫中心，但是進行了有效的管理和記錄，說的結論是，這樣很好！但別忘了改進！
這就是我今天給大家講的一些主要心得，希望能幫助大家開拓一些思路，同時也歡迎大家和我進一步探討，謝謝！
CIO時代網記者：非常感謝劉老師給我們帶來ITIL V3專業的知識講解、實施建議、以及評估指導，如果有對ITIL V3以及IT服務管理領域感興趣的網友可以跟CIO時代網或者劉老師保持溝通，進行更多的交流！謝謝大家，本期節目到此結束，下次再見！
---------
RACI是一個相對直觀的模型，用以明確組織變革過程中的各個角色及其相關責任。 我們知道，變革過程是不可能自發或者自動進行的， 必須有人對其進行作用，促使進程發生變化。 因而，就很有必要對誰做什麼，以及促發什麼樣的變革進行定義和描述。
除了RACI以外，還有RASCI或RASIC都是用來描述變革過程中的角色、任務的。
RACI的具體含義 英文縮寫
· 誰負責（R = Responsible）， 即負責執行任務的角色，他/她具體負責操控項目、解決問題。
· 誰批准（A = Accountable）， 即對任務負全責的角色，只有經他/她同意或簽署之後，項目才能得以進行。
· 誰支持（S = Supportive）， 即提供信息資源，輔助執行任務的人員。
· 諮詢誰（C = Consulted）， 擁有完成項目所需的信息或能力的人員。
· I =應該是消息靈通的。 即擁有特權、應及時被通知結果的人員，卻不必向他/她諮詢、徵求意見。
RACI模型通常利用RACI表來幫助討論、交流各個角色及相關責任。（參見右圖）
RACI的步驟
1. 辨識整個流程、找出各項活動，將它們記錄在RACI表的左側。
2. 辨識流程、活動中的所有角色，將它們記錄在RACI表的上方。
3. 完成RACI表的方格單元： 辨識每一個流程、活動的角色（R、A、S、C、I）。
4. 每一個流程最好只有一個“R”角色，這是RACI的一般原則。 當一個流程找不到“R”角色時，則出現缺口。 當一個流程有多個“R”角色時，則出現交疊。
5. 解決交疊問題。 每個流程只能有一個“R”角色，以便明確流程的具體擁有者和責任。 如果不止一個“R”存在，那麼就要對該流程進行再分解，然而再對“R”進行分配。
6. 解決缺口問題。 如果某個流程找不到“R”角色，這時對流程或項目負全責的權威人士則應該在現有角色中（或者發現新人選）挑選、任命一人擔任“R”。 更新RASCI表，對各個角色及其相關責任進行闡述
RACI