以下是現場速記。
卓尚服飾CIO 桂益龍
桂益龍：今天非常開心，感謝范總的邀請做這場分享。
其實我覺得第一場剛開始的時候，王總在非常宏觀和生態層面談了他的看法。我覺得宏觀是我們需要去看清楚的部分，但是今天我的分享更多是站在微觀的層面去看，我們到底能做些什么事情。就像范總講的我們的主題IT能做什么?
我們另外還有一個視角，IT部門始終是會去說我們能不能幫業務部門去做些什么事情，能夠為業務部門做一些賦能?反過來我在這兩年一直在思考，數字化能幫我們IT部門自己能不能提升我們的運營效率?如果自己都不行，還能說你幫別人嗎?
我最近在這一段時間一直在思考并且也做了一些實踐，所以趁著這個機會來跟各位做一個匯報。
我們會去分析看，我們在為業務部門數字化賦能方面，我們會幫助業務部門，不管是在零售還是在剛才講的會員運營，或者是說我們的商品運營，在我們的銷售到我們的供應鏈甚至人資和財務，我們都希望在各個方面幫助業務部門進行數據化、數據分析、找出問題，得到改善提升運營服務。
但是你會發現IT部門就不是這樣，大家每天忙于日常運維?？赡軙驗橐粋€工單沒有完成，我們被業務部門投訴，或者因為一個需求沒有及時交付，被業務部門表示不滿。在項目管理方面是否能夠很好的按期達成保質保量?包括我們的IT資產是否我們真正能管到每個人、每個IT資產的運營狀態，整個全流程、全過程的管理?
以及我們IT部門在整個過程當中，我們會需要很多知識解決問題，我們這些知識是否得到沉淀?這個都是打問號的。我了解到我們很多還是用excel表管工單、需求、項目管理、IT資產，或者有些零星系統或者有著單獨的工單系統去零星的管。所以我們IT部門很大的狀態是手工化的，是零星的在管這些事情。
我們還是想站在業務端來看IT部門，我們IT部門在我們業務端里它應該是什么樣的形象?我認為至少有三點。第一點是IT部門應該是很專業的，在IT方面;第二個方面我們是非常有態度的，業務部門對我們的滿意度是比較高的;第三個方面是我們還要追求效率。我們不可能把我們團隊永遠越做越大，有可能的話用最少的人去完成更多的工作。就像剛才飛書鄭總分享的，IT部門是叫效率工程部。效率工程部幫業務部門提升效率，IT部門的效率在哪里?有沒有數據化進行展現?
所以如果從專業層面來講，整個IT服務流程是否是規范的是否是高效是否是透明的是否是能形成閉環管理的?我們的客戶滿意度，我們在服務整個過程當中能夠隨時的了解客戶對我們的態度以及最終的評價。
這是我們要去思考的部分，我們在想我們要專業，我們在軟件研發里面的CMI就是成熟度，整個IT運營依然是有成熟度的。我們可以把成熟度分為五級：第一級是初始級(有工單就派人搞定)，第二級是已管理級;第三級是已定義級，如果能做到定義級，我們所有的流程都是有標準流程和服務的，它能實現閉環管理的;作為IT管理人至少要達到三級，這樣才對自己有個交代。第四級是量化管理級，第五級是優化管理級。
我們本身怎樣提升業務效率或者工作標準?第一個是ITIL，它本來是個國際組織提供給我們作為IT服務里面的標準的組件。在這里應該是有34個組件，我大概把它歸歸類，有規劃層面的，有執行層面，有服務層面，有效率層面的。這是我們做IT人去思考的，其實我們是有服務標準可以參考的部分。
第二部分是項目管理。我們會做很多項目，希望這些項目賦能我們的業務。其實項目里本身就有九五至尊，九大知識領域五大過程，我們第一能不能及時按項目當初規劃的要求完成項目?這樣我們在下面整個過程當中是否規范的推動，且能不能讓這些知識得到沉淀?以及未來得到復用。這是關于項目管理。
作為IT主管或者IT人來講，我們每天的工作，我們整個工作到底是哪一些?我們可以稍微劃分一下。在我們整個分析里面，在左面部分是規劃層面，右邊部分是我們IT人要日常運營的部分，一個是規劃一個是運營。
在規劃層面，我們是會分幾步去走。第一步是業務分析，第二步是服務組合，第三步是戰略規劃、架構設計、組織規劃和IT運算。怎么去看?剛才王總講我在業務層面我會要做一些創新，比如我要做預制菜，把它做強做大。
我的業務有變化了，或者我們從批發轉向零售，從線上要加上線下，這些都是叫業務分析，我們發現業務有變化了。作為IT人要對服務組合進行調整，原來只需要批發系統，現在需要門店數字化的系統。原來做的是線下可能要更加注重線上更加注重會員系統，這些都是服務組合的調整。是因為來源于業務變化，所以需要調整服務組合。
有了這些東西才會談到IT規劃的調整?？梢赃@樣講當我們業務沒有變化的情況下，我認為IT規劃每一年抄下去就可以了，因為業務沒有太多變化，所以不需要調整太多的IT規劃。有了這個東西之后，我們會再一步調整架構，我們要上什么系統。所謂組織規劃是向公司要多少人，原來20人，現在需要增加5個人，這5個人專門針對會員運營的，組織要進行調整，接下來是IT預算。
所有起點來源于業務分析，但是這個事情第一是IT主管要做的，第二我認為大家都是行業專家，我認為一個月搞定了或者年底搞定或者年初把事情搞定了。我們更大部分的工作應該是在我們的日常運營，我們又把這些工作分成幾個部分，第一部分是基礎設施，電腦網絡這些部分。然后是服務工單以及我們原有系統的需求變更，再往上是我們項目管理，另外還有是我們和業務部門陪跑做業務運營。
我認為每一個項目我們最終要拿成果一定要和業務部門陪跑，我深知認為在剛開始在這一項目里，我們是教練，業務部門是學生。因為這個工具，我們一定比業務更熟。我打個最最簡單的比喻，在我2021年10月份之前我在羽絨服公司工作14年，2021年10月份來到杭州卓尚服飾，我很驚訝的發現我們竟然沒有做O2O，但我們要開始推動的時候我們是陪著業務部門開始做O2O的操作手冊，做O2O培訓、獎勵制度、規劃，每周陪著他們一起去看我們O2O的運營數據，這些都是業務要做的，實際這部分是最能拿成果的部分。
在分析業務之后，我們就可以開始想我們該怎么干，我們怎么去把我們的業務進行數字化。我認為這部分不是太需要數字化的，可能用一張PPT就能搞定的事情。但是灰色部分是可以做數字化的，因為它是長期的循環的每天每周每日每月都要去做的事情，業務運營成果也是要的，但是我正在考慮怎么讓它數字化。
所以我大概捋了一下，我們作為IT來講，我們自己來講怎么樣數字化?大概是哪些內容?
第一項內容是日常服務。日常服務里面，第一項要做的事情第一把服務要進行清理，生成我們的服務清單。我們到一家餐館點菜一定要有菜單，作為服務人員需要服務目錄。第二針對不同的服務目錄要制定不同的服務標準，你是去修個電腦還是響應個需求，我相信這個時間肯定不一樣，或者你是開個郵箱，開個郵箱估計5分鐘就搞定，修個電腦可能需要半個小時或者多長時間。
我們有服務目錄，有服務標準，然后我們還希望我們的用戶能夠再查詢到我們的服務，就像我們電商下訂單要看得到有沒有揀貨、發出，我們也希望用戶看到，最后服務得到用戶的評價。
第二部分作為IT來講一定會遇見的事件和故障，每一個事件和故障都希望得到記錄、復盤。當我們下次遇到同樣的事件或同樣故障的時候，我們能夠快速的把它處理掉。
接下來關于需求變更，我們如果公司規模比較大，可能一年有上千個需求，當然小的可能一兩百個需求，我相信一定是有的。這些需求第一發起完了之后有沒有方案?有沒有得到業務部門的審批、通過?我把這些需求派給哪個開發的同事?哪個測試的?最后有沒有發布，發布有沒有成功?如果沒有成功，沒有成功的原因到底是什么?要進行全過程的記錄。
接下來是項目管理。從項目準備、建設、上線運營以及我們的運營維護，這一部分我們也希望得到全程的記錄和進度的管控以及最后形成我們IT資產。
最后要形成知識管理，知識來源于工單、需求、項目、事件和故障處理。
這個是我花了一年多的時間，我們自己部門自己開發的一套ITBOS系統，IT的運維系統。這個是我們整個IT部門用這套系統來管理我們的日常業務，在這套系統里是包含了基礎管理、IT資料，IT資料包括所有的人員、服務目錄、服務標準都要在這里設置，工單管理、事件管理、故障管理、需求管理、實現管理、發布管理、項目管理、資產管理、備件管理、知識管理以及統計分析報表。這三項就是一個項就是知識管理，但是我們要把它細分。
這個是框架，我們進入系統之后知道這是我們的界面，可以看到工單、事件、故障、需求以及IT資產大概的整體情況。
接下來我快速把每個模塊進行簡單的介紹。
第一塊是關于工單管理。業務部門所有的工單提交的話直接扔到服務臺，在服務臺里，我們可以用派單模式也可以用搶單模式。提交完之后進入工單池，然后接單然后進行過程跟蹤，甚至可以跟蹤到一線、二線、三線、四線，有的工程師基本上一接單都能處理掉，有的工程師要轉單，因為能力不夠，我們要去記錄下來。當然有的可能還會轉三線、四線，所以進行跟蹤管理，完成之后最終用戶要評價，評價完之后要形成知識沉淀。所以在這里整個工單形成了管理閉環。
在這里會記錄每個部門每個用戶所提交的工單，我們也會記錄每個工程師什么時候接單，什么時候完單，最后用戶打分評價。
再一個是事件，所謂事件是未來要形成故障可能的那些東西。比如說我們的CPU，我們使用率已經達到80%了，再往上負載高的話系統要卡掉了，這是事件。比如硬盤容量已經使用了80%了，我們再往下可能也跟系統一樣。所以我們要把這些事件記錄下來。
而且我們可以通過事件的登記，可以看到我們工程師有沒有監控，如果一年到頭沒有這個事情，這是不可能的事情，一定會有事件發生。如果很好的把這些事件進行登記處理形成我們知識沉淀之后，它一定會預防我們的故障。所謂的故障就是整個系統不可用，整個系統就掛掉了。說實話我們在去年一年我們自己公司也遇到兩三起的故障。
這些故障第一我們要登記，第二我們一定要把它快速處理，還要分析原因，然后是解決方案，形成我們的知識沉淀，中間我們還要做可用性分析。因為我們經常會說我們做IT部門，我們要保證業務運營系統，可用率是99.9%，我們的數據呢?如果我們沒這個登記，沒這個數據，那只是拍腦袋或者跟領導吹牛而已，如果有這些數據完全可以跟領導去講，我的這個系統我們今年可用率是100%，因為這套系統從來沒出過問題，那套的可用率是99.6%，我們中間發生過一個問題，停機了一個小時。我想這個都是我們可以量化的工作。
接下來是需求。第一部分是當我們業務部門提交需求之后，一般正常來講會有內部的業務顧問，對接業務顧問，給他做方案，我大概多長時間完成，給到之后要業務主管審核，這個非常關鍵。
以前我們曾經遇到過業務主管都不知道下面提了需求，結果我們改了發布上線之后，業務主管說怎么改了?他說我是主管我們怎么不知道?我們有了這樣的規劃方式，可以更好的合理控制這些需求，而且能保證這些需求得到落地。
我不知道同事有沒有遇到過這種情況?最后這個需求改完沒人用，因為沒有得到業務部門主管的確認，也沒有審核推動這個事情，他認為這個東西不重要。我們希望完成這個需求之后，用戶進行打分評價，最后形成我們的知識。
這個是從需求提交到審核的過程，我們現在需求還有一個實現的過程。很多公司用的都是接納，就是做需求管理。在需求管理里，需求完了之后我要派工，然后我還要做測試，有沒有測試，有沒有OK。過程當中，我們還可以做工作量登記，滿足這個需求的時候，我們哪個公司有多少工作量?以及我們在測試的過程當中還可以看得到我們到底開發完給到測試，給測試人員打回來多少次，我們通過這個是可以知道每個開發人員的開發質量是多少。
當我們一個部門開發人員有20個的時候，實際是很難知道每個開發人員的真正開發質量。如果沒有數據，只能是拍腦袋感知這個人大概水平可以。什么叫水平可以?如果真的有這些派工資料、測試數據，我們的完工工單情況，而且當初我們講這個需求開發需要5天，最終交付的是5天還是6天還是幾天?我們也可以看到他的整個效率是多少。
測試完成之后我們就會進到發布池進行發布，作為系統進行發布還是非常重要的。第一有的發布是不需要停機，有的發布需要停機。如果我們的發布需要停機，而業務部門不知道，業務部門認為是個故障，系統壞掉了，因為他不知道。所以做IT系統來講，當我們真正要停機的時候一定要通告我們的業務部門，我大概是在晚上的10點到12點，我要停機發布我們的系統，甚至發布完之后我們告訴一聲發布成功大家可以正常使用了。
只有這樣才能表現出我們作為IT人是非常專業的，要不然他不知道，他什么時候系統不能用，他不知道到底是真正系統掛掉還是你在發布一個系統。而且我們在發布之后，還需要去登記，發布有沒有失敗還是成功。因為我們只有這樣才能知道到底我們的交付質量是什么。我以前一年總歸好多次發布失敗，我們要去做回滾。
接下來重要的一塊是關于項目管理。我們講項目管理本身有九五至尊，以我現在的經驗我們只需要四個階段，第一個階段是項目準備，就是到項目啟動會開始之前都叫項目準備，包括項目合同、項目章程、項目啟動會等，大的項目應該有這些流程，小的項目可以沒有。但是有的東西一定要有，包括項目組成員、項目計劃，甚至開項目啟動會也可以，一個項目至少有兩個必須要有的。
我們在項目實施階段一定會有需求調研，調研完了之后需求規格說明書以及我們的設計或者藍圖，詳細設計，我們的開發文檔以及我們整個功能實現，最終下面的是叫用戶接收報告。用戶接收非常重要，如果一個系統在上線之前沒有用戶接收報告，未來上線不成功，可能只能IT部門自己一個人背了。如果有了我們業務部門的上線驗收報告的話，如果不成功，至少來講有50%是業務部門跟我們一起背的。我相信通過這種方式可以讓業務部門更加非常重視這個項目，非常重視這次上線。
上線前還需要一系列的動作，包括上線方案、上線發布、上線通知、操作手冊、培訓記錄、上線數據準備以及上線報告。甚至有的時候上線之后發現有人不會做，你可以說有操作手冊、培訓記錄。
上線方案也很重要，因為上線前會牽扯到業務很多的調整，比如說上一些大的項目的時候，甚至我們的倉庫、物流包括生產方面都要做調整，包括財務都要做調整。我們以前上一個大項目的時候，我們財務提前五天結賬，我們停止五天原副材料領清，為了盤清原副材料等。上線一定會有問題，出上線清單，最后驗收總結。
不是每個項目都要這么去做，這些東西可以裁減，我這個項目如果是小項目，我哪幾個階段需要，或者我的項目比較大，哪幾個階段是比較需要的。最大的區別是有的是外購項目，有的是自己內部的項目。外購項目有項目合同，內部就沒有項目合同。
接下來是關于IT資產，我們有一系列的動作。包括我們的資產入庫、資產領用、資產歸還、維修登記、更換登記、資產盤點、報廢、處置，它是有一系列這些動作的。
包括我們備件，IT部門有很多備件。我們的備件到底用哪里去了，有時候說不清楚，如果有備件臺賬就可以知道備件的用法，或者有了臺賬之后發現我們的備件不需要用那么多。
最后我們是知識管理。知識管理不是單獨做的知識管理，而是在各個階段讓它沉淀下來的。比如工單、事件、故障、需求和項目管理，這些所有的動作都是有很多東西自然而然就形成了我們的知識。
舉個最簡單的例子，我們在前一段時間發現我們BI服務器突然卡住了，怎么辦?要不然換服務器，換服務器來不及，后來我們就查知識里發現把服務器關掉，把兩顆CPU拔下來重新兌換開機就OK了，如果沒有知識管理，我們肯定是不知道的。我只是舉這個小例子，實際知識管理對業務服務效率提升是有幫助的。
我們還是做了兩個面向用戶的移動端，這一塊我們放在釘釘上，當然也可以放在飛書上。我們作為用戶來講，它在手機端可以提交它的需求，提交工單管理個人的IT資產以及我們的需求提交，所以我們用戶部門可以提交需求、查看進度、評價服務以及知識應用，可以自己做知識轉出或者知識轉入確認，以及他提交需求、評估需求、審批以及交付之后的評價。
這是移動端，我們在PC端也做了一個，提交工單、需求以及知識查詢。其實對用戶來講很簡單，剛才那個復雜的管理都是給IT部門要去使用的。
我想作為IT主管來講，我們可能重點要關注哪幾部分?
第一部分關注異常。我的工單有異常，我的需求有異常，超期了，我的有事件、有故障，我的項目我要關注這些異常。第一個要關注異常。
第二個關注效率。IT自己部門的效率，要看到接單、完單、轉單的情況。
第三個是關于客戶滿意度?？蛻魧ξ覀兊脑u價到底是什么?
第四個是綜合分析。
我們一年做下來之后我們作為IT部門自己的成果是什么?我們通過數字化運營是不是有進步了?以工單舉例，工單接單時間原來需要2.9小時，現在需要1.3小時。完單時間也縮短了，原來基本要平均3.98個小時才能完成一單，現在只要2.15個小時以及最終客戶滿意度，我們是五分制，如果客戶不打分不評價就是四分，客戶主動打分評分，我們會加上去，我們整體下來是4.2幾分，其實也是不容易的。
因為我們效率提升之后，我們花了比較多的時間和業務部門陪跑。所以我們在其他項目方面，我們其實幫助業務部門實現了比較好的業務價值。比如說我們在機器人項目里面，我們和電商的一個部門就用機器人一年替代40幾個人的工作人天。
作為數字化部門來講，業務部門有那么多數字化，作為IT部門應該也有這么多數字化，去管控我們異常，提升我們效率。我認為IT和業務就在一條船上，我們要把業務部門從這邊渡到那邊，我們自己也要做，所以我叫做自渡&渡人。
我們要做有專業、有態度、有成果，做業務和領導信賴與尊重的IT人。對我們感興趣的甲方，請掃那邊，乙方同學請掃這邊。
非常感謝大家!
京公網安備 11010502049343號