近期由于工作需要，重新把以前丟掉的IT服務管理的報表體系與指標體系撿起來想了想，原來有過一個想法根據(jù)指標去設計一個服務管理系統(tǒng)，后面各種原因未能成行。現(xiàn)在的管理軟件越來越多，越來越復雜，也越來越靈活，但我總覺得基本都是沒有靈魂的產(chǎn)品，在設計一個管理軟件時，設計師的思想是非常重要的，無論一個軟件多么靈活，但在設計師的腦中一定有一個最好的組裝形態(tài)，在它的背后需要有一系列的管理取向去支撐著，這會體現(xiàn)出設計者的管理哲學和把握事物本質的能力，遺憾的是，許多優(yōu)秀的產(chǎn)品的設計思路沒有被傳導出來，實施者們并沒有理解產(chǎn)品的功能設計，或者是無法把這些分散的功能組織成一套管理體系，由于靈活度的問題或定制的問題，最后實施出來的東西會離設計者的思考很遠，這是一個方面，另一方面，一個良好的管理軟件是不可能離開良好的報表設計的，設計者在設計之時，就需要考慮好用一把怎樣的鏡子去照射出業(yè)務過程中的扭曲或問題，這個鏡子就是報表，它可以引導業(yè)務走向設計者的設計目標。

　　一談到報表，人們馬上會聯(lián)想到指標，KPI，這幾個概念相關之間是有關系的，許多人對這些名詞并不做嚴謹?shù)乃伎迹@些詞語只是一個個的從他們的嘴里蹦出來，或者當他們提問時，他們甚至根本沒有考慮過這個問題意味著什么，就如蘇格拉底所說的，我們首先需要定義我們的問題，所以有必要我們去把最基本的概念去理一下，比如，指標是什么，報表是什么，什么是KPI，這三者的關系是什么?。

　　指標是用來分析指出某種情況的，它代表了測量者對某種狀況的信息渴求，指標事實上是先于報表而存在的，所以是先有指標才會有報表，而不是先有報表后有指標，當你不明確你需要了解什么時，你的信息一定是泛濫的，所以現(xiàn)在許多管理軟件的報表多而雜亂，尤其是定制化程度高的軟件更是如此，畢竟優(yōu)秀的分析者是稀缺的。如果我們需要知道一個公司需要有哪一些報表，首先需要回答需要哪一些指標去反映我們的現(xiàn)狀，而這個問題最終會回歸到管理體系的層面，一個全面而均衡的指標體系或報表體系是離不開一個良好的管理體系的，本質上這些都是業(yè)務設計或規(guī)劃的問題。

　　事實上我們可以有一些方法或步驟去設計我們的指標體系，即便是它目前可能不是那么好，但仍然可以建立一個大致的框架，先去收集整理現(xiàn)有的指標有哪一些，會形成一個清單，收集的方法可以基于不同的崗位或角色，從上到下的進行收集，一旦收集完成后，你才會發(fā)現(xiàn)我們現(xiàn)在關注的東西是多么低級或殘缺，然后需要對指標進行一些分析與整理，大致步驟如下：

• 定義指標的作用：中國的管理現(xiàn)狀是，領導們隨時會想要不同的報表，當他們想要時，他們自己未必知道自己真正想要什么，這種行為象小孩子一樣，不同的是是下屬變著花樣的編報表滿足他們，他們會玩一段時間后就丟了，然后過段時間說沒有新鮮感，要換個玩法。我們可以改變一種方式，從領導的個人角度出發(fā)，你永遠只能做出滿足一時的報表，便你從業(yè)務本身出發(fā)，你有可能做出一個全面而均衡的報表體系，它可以滿足不同的角色在不同的時間的不同信息需要，因為業(yè)務本身其實沒有變化。所以我們需要嚴格檢視每一個現(xiàn)有指標的意義與作用，到底這個指標要來做什么?
• 定義指標使用者：每一個指標的檢查者及承擔者是誰，這是第二個需要回答的問題，指標有了之后，需要有人去分析它或查看它是多少，當你有了一個完美的指標但沒有人看是沒有用的，有人看，但這個指標沒有任何承擔者也是沒有用的，指標的意義在于可以衡量我們的現(xiàn)狀，它類似一個GPS告訴我們現(xiàn)在處于什么位置，所以帶來行動是它的終極目的，每一個指標出來后需要定義出誰來查看它，甚至需要定義出它的查看或回顧方式，比如是以會議的形式還是肉眼瀏覽，就象變更成功率或發(fā)布遵守率，你需要有一個角色的人員去關注這二個指標，分析這二個指標的人得清楚誰需要為這二個指標的改進負責，當每月需要進行指標分析，可以責成承擔者解釋原因或采取行動。
• 定義告警值：當指標達到多少時，就必須采取行動進行干預，你不能等到油箱的油燒完了，才告警，這時車都不動了。此時我們會發(fā)現(xiàn)我們不能把一些基于的事實數(shù)值當成指標，比如事件數(shù)量，我們需要把事件增長率，或事件下降率當成指標，絕對的事件數(shù)量可能是沒有意義的，一個大型系統(tǒng)的事件量每天可能幾十個，一個小型的事件量才幾個，所以對一個大型系統(tǒng)而是言一天增長或下降幾個事件很正常，此時用事件增長率或下降率做指標時，這樣無論大型還是小型系統(tǒng)都可以拉到一個平面上做分析，這樣可以計算出平均系統(tǒng)事件增長率了或做排序了。事件下降率的指標可以強制管理者分析進步的原因與機理，所以指標不僅僅是用來關注負面的。
• 定義測量范圍：同一種指標可能會因為測量范圍不同而出現(xiàn)多個，事實上這是一個指標分解的過程了，比如當定義一個變更成功率的指標時，而公司總體而言會有一個變更成功率，但分解時，會得出每一個系統(tǒng)或服務的變更成功率，此時背負指標的人員與指標檢查者會有所不同。
• 定義數(shù)據(jù)來源：一些看上去很好的指標，最后很可能是無法采集的，因為它沒有確切的數(shù)據(jù)來源，我們需要弄明白每一個指標的基礎數(shù)據(jù)取自何方，是哪一些系統(tǒng)或是哪一張表單。
• 定義數(shù)據(jù)信息：確定指標由哪一些基礎數(shù)據(jù)構成，確定它的所有列或字段，比如平均事件響應時間這個指標，可能包括的字段有：月份、服務名稱、事件類型、平均事件響應時間這幾個字段。
• 定義計算方法：確定指標的計算公式，比如通常所說的發(fā)布遵守率，大家都知道用總發(fā)布遵守數(shù)量除以總發(fā)布數(shù)，但總發(fā)布遵守數(shù)是否包括提前發(fā)布的數(shù)量?或者是否包括緊急發(fā)布?總發(fā)布數(shù)這個分母到底從哪一時間點起算，如果算每月的發(fā)布遵守率的話，總發(fā)布數(shù)是本月所有發(fā)布的總數(shù)嗎?是否要剔除緊急發(fā)布?是否剔除發(fā)布失敗數(shù)?是否剔除提前發(fā)布數(shù)?
• 定義測量頻率：指標設計好后，必須確定多久進行測量一次，如果這個測量頻率定好后，你會發(fā)現(xiàn)你的日例會、周例會、月例會、季度例會、年度總結會的核心內容基本上都定義好了。
• 是否納入KPI：指標成百上千，但在一個歷史時期中，人們的精力總是有限的，我們只能把行動放在最需要關注的狀況上，所以每一年我們可以從指標集中選取出一些納入到KPI之中，當狀況改善后，我們又轉向另外一些指標，這些就形成一個PDCA的過程。

　　上面說的幾個步驟，事實上可以形成一個表格，形成一個公司的指標庫，然后每年進化，事實上在設計指標的過程中，由于定義了數(shù)據(jù)內容與計算方法，報表的產(chǎn)生是自然而然的，一定要設計好分析之后的行動或產(chǎn)出，并形成記錄，報表不是用來愉悅領導的，我們要想好當一個人員看完它之后應做什么，這個做的動作不應是由由這個個體來臨時決定的，而是要提前設計并約定，這樣才把管理者鎖在管理體系之中，而不是讓他們成為體系最大的破壞者。事實上當把指標的閥值設定好后，指標異常是無須用肉眼去分析看查看的，當一個事件的增長率突破了20%或50個的絕對數(shù)量時，是完全可以用邏輯的計算方法得出異常的原因分布的，你可以把利用事件的類型、申報部門、事件等級、事件時間、系統(tǒng)服務、關聯(lián)的配置項屬性等進行邏輯的窮盡演繹，所以所謂的圖形鉆取事實上意義不大，因為它依據(jù)人腦來做邏輯的演繹，而一個表單的字較多時，你不可能用肉眼把每一個種邏輯組合全部查看一遍，你的腦子也不可能記得清楚這些邏輯組合，這個層面就開始進入了BI的層面。

　　另一個值得一提的是指標的均衡性，當指標體系本身不全面時，一昧的以運動方式去追求單一指標，會帶來一系列的惡果與虛假現(xiàn)象，所以指標有時是一個與人性博弈的過程，比如當我們非常追求事件解決率時，可能會帶來滿意度的下降，當我們非常追求事件響應時間時，員工會有單就先接單再說，這樣事件的處理時長會大大拉長，當你關注事件的處理時長，他們可能又會把事件掛起(事件等待的時間一般不計入事件處理時間)，這些類似的情況很多，這也是為什么指標要成體系的一個原因，就如人體一樣，你片面的追求體重指標，可能犧牲了其它健康指標。你片面追求GDP指標，人民的幸福感卻不斷下降，這些道理是類似的。

　　說到一個IT服務公司或一個內部IT部門的指標或報表體系，往往有人會繞不開SLA，許多人認為SLA報表就是報表體系了，但事實上SLA只占到報表體系中的很小一塊，一個完整的指標或報表體系是要面向整個業(yè)務過程的，要了解一個事物，必須通過不同的切面去剖析，了解一個人，你需要知道他的外貌，他的性格，他的職業(yè)，他的生活，他的愛好等等切面，對于IT服務或IT運維而言，可以用幾個不同的面向去解構它，每一個面向都是一種管理角色去關注它，這種解構的原則要做到完全窮盡、相互獨立，以下分別說明：

1. 面向服務：首先需要關注的是服務，這是很重要的一個切面，這個層面的指標或報表以服務經(jīng)理的角色為主，服務的指標可以分為結果類與過程類，結果類又可分為SLA類、OLA類、UC類，這主要是指契約類的承諾達成情況，或者說是服務質量結果，比如象電話接通率、事件響應時間、事件解決率、事件滿意度、系統(tǒng)可用性這些跟SLA相關的，跟OLA相關的象發(fā)布的遵守率、故障解決時長、事件響應時長等等。過程類主要是對服務過程本身的監(jiān)督或質量檢查，比如事件增長率、投訴事件數(shù)、剩余事件比率，這些指標的設計目的是提前感知、測量服務的變化情況，提前預防質量問題。
2. 面向對象：對于IT服務而言，最基本是要保障IT架構的正常，有了這一層的保障，IT服務不會出現(xiàn)大的問題，而IT架構其實就是由一個個的對象所組成，所以需要有一個從對象的視角出發(fā)的指標來監(jiān)控IT架構的狀況。所以既然有一個角色負責服務，同樣需要有一個角色負責架構，這一層的指標源數(shù)據(jù)與監(jiān)控系統(tǒng)有比較多的關系，對象類的指標可以根據(jù)不同分類進行展開，這個分類可以與CMDB的CI分類為準，比如主機類、網(wǎng)絡類、安全類、軟件類、數(shù)據(jù)庫、中間件、存儲類、動力類，每一個分類都根據(jù)各自的特性再行分細分，比較主機可以分為性能、狀態(tài)、故障這幾個方面的指標，比如主機類的性能主要是指CPU與內存、IO的負載情況，狀態(tài)主要是目前的機器的啟用率與健康率，故障主要是指目前機器的故障信息。
3. 面向流程：IT服務的三權分立，前面講了服務層面與架構層面，還有一個比較重要的層面是流程層面，這個層面在許多公司與服務層面沒有切分清楚，造成了管理缺位，服務經(jīng)理主要是管理實際的IT服務的，而流程經(jīng)理主要是管理流程運行的，兩者的關注點是截然不同的，流程的指標可以根據(jù)流程進行切分，或者根據(jù)ITILV3的生命周期切分后再根據(jù)流程切分，比如服務運營就包括：服務臺管理、事件管理、事故管理、請求管理、訪問管理等，服務強管理的指標可能包括：首問解決率、事件錯派率、事件回訪率、話術錯誤率。事件管理可能包括：一線解決率、二線平均響應時間、三線平均響應時間、事件平均解決時長、事件關閉失敗率、變更導致的事件比率等等。
4. 面向人員：在組織的層面，主要關注單位與個人的指標，這主要是由管理者與員工背負的指標，可以用來做績效考核，比如部門層面會有一些象員工流失率、服務滿意度等指標，個人的指標會為事件滿意度、關單及時率與一些行為績效方面的指標。
5. 面向財務：針對財務的層面，主要關注營收的指標分析、與成本的指標分析，以及預算的指標分析，

　　以上的5個方面構成一個指標框架及報表框架，事實如果做服務的門戶，這些指標就完全可以支撐了，需要做的是基于組織的當前情況，利用前面說的方法去完善這個框架內部的指標細項。指標的測量本身會帶來許多有意思的現(xiàn)象，這有些象量子力學的概念，你的觀察本身會改變事物本身，所以即便是你什么行動也不做，只是每月的把相關有人員拉在一起查看指標結果，業(yè)務本身的運行也一定會改變，一旦你建立自己的指標體系，真正開始PDCA，你會發(fā)現(xiàn)它的威力非常巨大，可惜的是每一個公司都在找標桿，不愿自己埋頭獨立思考與作業(yè)，這就造成大部份公司的管理體系或報表都比較糟糕，其實上在中國一個具有一定IT規(guī)模與基礎的公司，只需要花一兩季度的時間就完全可以設計出一個中國一流的指標及報表體系，因為大家都在找別人的東西，不愿抬頭想，不愿低頭干，標桿其實就是提前走一步的人建立的。