劉北京：互聯網時代下的科沃斯IT建設|V課堂第22期
5月12日，江蘇省企業信息化協會總群迎來第22期“智造+V課堂”。5月份，江蘇省企業信息化協會邀請四位資深民營企業大咖，和會員一起聊聊“民營企業信息化那些事”。五月第二期“智造+V”課堂邀請了科沃斯機器人有限公司信息總監劉北京，他為大家奉上了主題為《互聯網時代下的科沃斯IT建設》的精彩分享。
演講大綱
1.科沃斯公司運營及產品線介紹
2.科沃斯IT建設目標及前后發展狀況對比
3.科沃斯IT基本架構及項目介紹
4.科沃斯IT戰略管理
演講嘉賓
劉北京，科沃斯機器人有限公司信息技術總監
劉總履歷
15年IT管理和信息化推動經驗，8年企業IT總負責人?，F任科沃斯信息技術總監，曾任神達電腦、中聯重科IT負責人。他主要關注于IT戰略和策略落地、全球治理架構、IT項目管理和品質控制體系、信息安全、物聯網、銷售和產品互聯網化等模塊，熟諳Sap ERP、Oracle EBS ERP、CRM、MES、EWM、PLM、SRM、SCM、BI、APS、e-commerce等業務領域知識，并對分布式架構、大數據建設、云建設、技術架構、敏捷開發等技術領域有著豐富的實戰經驗。
原文實錄
大家晚上好，謝謝陳總，謝謝江蘇省企業信息化協提供這樣一個機會，讓我們大家今天可以相聚一堂，同時也非常感謝大家今天晚上下班以后坐在一起來聽分享，辛苦了。我是來自科沃斯的劉北京，今天我應該是把在過去的兩年里，在科沃斯工作的一些情況跟大家簡單的做一些分享，然后簡單的做一些介紹，讓大家可以有所收獲。
我今天的分享應該是分以下幾個部分，第一，我會整體介紹一下科沃斯的整體業務情況，第二，會把科沃斯在IT建設過程中遇到的一些挑戰跟大家分享。同時，也會跟大家分享一些階段性的項目，IT建設成果，以及個人對IT的一些理解。實際上IT建設是離不開公司支持的，也會跟大家簡單分享一下IT在公司的戰略定位?？莆炙故侨绾稳ニ伎糏T的?最后簡單的跟大家分享科沃斯的IT是如何治理的?
科沃斯的業務主要有三類，從事業部來區分，一類是家庭服務機器人，一類是商務機器人，同時我們還有一個事業部是我們的代工產品事業部。
家庭服務機器人就是大家經常用到的掃地機器人，掃地機器人目前在整個中國的市場占有率是60%-70%。還有一款是清潔機器人，是我們的沁寶，就是空氣凈化機器人。科沃斯所有的機器人都有一個特性就是，都會自主的移動，有自主的路徑規劃，會自動的去巡航，會去自己做清潔。我們還有一款擦窗機器人，現在高樓越來越多，無論從風險，還是從人工成本來講也是越來越高，整個擦窗系現在非常流行。我家住在14樓，其實我們陽臺玻璃的清潔都是非常困難的，擦窗機器人可以自主到戶外去做玻璃清潔，這樣也比較方便，同時也是比較安全。我們還有一款家庭機器人是我們的親寶，應該是管家型的機器人，管家型的機器人它可以具備地面清潔的能力，同時可以具備空氣清潔的能力，同時它會在家里有基本的一些屬性的檢測，它可以檢測到家里有沒有陌生的人到家里來，比如家里的寵物有沒有在動等等之類的，我們具有家里的一些基本監控和管家的功能。
第二類是我們的商務機器人，商務機器人是一個新的事業部?，F在比較著名的有兩款產品，一款產品是導購型機器人，在去年銀行用的很多，它可以去導購，可以做一些講解，引導用戶去做一些體驗。同時我們還有一款產品是太陽能面板的清潔機器人，因為在一些大面積使用太陽能的地區，這些太陽能的面板長期被風沙附著到表面以后，發電能力相對來說會下降。所以我們有一款太陽能面板清潔的機器人，會在所有這些太陽能的面板上每一個區域自動清潔，清潔完了會到另外一塊。我也提一下，在科沃斯目前的一棟樓上面也安裝了很多太陽能面板，這些太陽能面板其實已經解決了整個科沃斯30%的電力供給。
我們還有一個事業部是我們的代工版塊，科沃斯應該是從代工，包括小家電起家，這塊也是我們目前相對穩定的一個業務?？莆炙箼C器人是1998年成立，它的前身是泰怡凱，主要是做代工，我們去年剛剛過了十八歲的生日。目前整個科沃斯員工有將近三千人，我們有研發，包括我們自己的生產供應鏈，我們的電商、我們的鏈條非常的長。科沃斯目前的銷售額將近30多億到40億人民幣，我們的機器人銷售額已經超過了我們的代工板塊。
我重點還是跟大家介紹一下我們的渠道建設，因為現在整個零售行業，包括電子類行業，大家都在拼命去拓寬渠道，科沃斯也是一樣的，我們有非常多的渠道。我們有在京東跟易迅的B2C渠道，同時還有一個非常龐大的線下渠道。早期科沃斯也是主要從線下發展起來的。同時我們還有自己自主運營的官網渠道，我們還有一塊很大的就是淘寶的渠道。商務機器人主要是走的B2B的渠道。
目前，我們在40多個國家有將近六百家門店，在德國、美國、日本有全資子公司?？莆炙乖?014年，就是我加入科沃斯那一年，整個科沃斯雙十一有1.52個億的全網銷售額，其中整個淘寶旗艦店當時銷售1.04億。我們在2015年整個雙十一全網銷售3.15個億，其中有一款機器人是朵朵掃地機器人，整體上銷售額一億人民幣。去年的雙十一，我們的官網商城貢獻了將近200萬的銷售額，今年整個官網日常銷售額應該可以達到200萬到300萬以上。
我剛才把整個科沃斯的一些整體情況跟大家作了簡要分享，現在再談談科沃斯IT建設的過程中的一些故事，包括我自己的一些看法。加入科沃斯之前，科沃斯的IT相對來說還是比較小，是掛在財務下面的一個科室，整體上的話會有10多個桌面運維人員，整個IT的運作效率還是比較低下的。有一個簡單的例子，我2014年到科沃斯，當時即使作為IT的負責人拿到公司配備的筆記本差不多也用了兩個多星期。所以整個公司的IT效率，包括IT對戰略的一些匹配，其實在公司的管理層認為說，還是遠遠不能達到整個公司管理目標的。
之前我也跟很多人做過一些交流，很多民營企業包括科沃斯，在高速成長的時候往往都會忽視IT的建設。在很多高速成長的企業里面，發展到一定階段，大家都認為IT是很重要，但是在真正需要IT的時候，大家的支持相對來說還是比較弱的。當時我以為科沃斯IT有基本性的支撐，實際上到了科沃斯跟公司的管理團隊在作交流的時候，沒有想到我們這么薄弱的IT建設支撐整個科沃斯這么大的業務。
我之前在臺資企業跟國有企業服務過很長時間，實際上我的體會是，在民營企業我們的資源還是相對來說比較少的，同時很多民營企業在高速成長的時候，意識到IT很重要的時候，就是我們要來做這件事情的時候，要求是非常高的，要求高來自于兩個層面，第一個是要求的時間是非常短，要在短期內建設成可能與公司戰略匹配的IT的層次。第二要求比較高，我們都是后來者，我們是希望彎道超車，我們希望可以建設到目前同樣行列里面的水準。
所以應對這種需求還是挑戰比較大，我相信可能在今天晚上分享的很多的人，其實可能都是大家在不同的行業，也在不同的這種模式的企業里面去在工作、在服務。所以大家面臨的這個IT建設的訴求跟情況也不一樣，所以我們當時是在解決這個問題，我是對自己在講說，實際上我們短期內要救火，我們要必須處理救火跟長期的運營之間，包括解決問題與長期體系之間的關系，簡單的說就是，有時要救火，如果不救火的話，可能一把火燒得大家都傷了。但是，如果說只救火的話，可能遠期又存在問題，因為不斷的發生火災，所以對這種相對基礎比較薄弱的一些IT建設狀況的話，需要兩手一起來抓，在救火的同時，我們必須處理遠期的一些需求。
其實我們當時也是總結講說我們一定要標準化、集成化、專業化，但是我現在想起來其實不外乎就是最好用成熟的框架、成熟的軟件、成熟的一些設備?？焖僖鲞@些施行，我們要作大量的一些IT應用建設的同時，必須掃清整個公司在建設過程里面一些基礎性架構的問題。
所以，我們在短期內解決了很多問題，當然也非常感謝一些合作伙伴，提供一些可借鑒的外部經驗及資源。其實我是程序員出身，真的有很多程序員，包括有很多做IT的管理人員或者IT的一些負責人，都是喜歡去證明自己有多牛，我到底能解決什么問題?我自己能力有多強?其實對我來看的話，我更關心的是，我有沒有支撐到公司業務。因為其實我們起步比較晚的話，我們一定會面臨一個最大的問題，就是我們的時間窗口問題。我們必須要快，就是別人踩過的坑我們就不要去踩了，別人有成熟的經驗我們就去借鑒，別人有成熟的設備我們就去用，有成熟的框架我們就去參考。不要自己去研究一些相對來說比較偏僻的一些技術解決方案。
我到科沃斯兩個星期，公司管理層在對我一次約談的時候，我有談到說，公司第一個的話其實是沒有系統，不是沒有系統，我們還是有一些小的系統，況且這些小的系統的話，在一定程度上也解決了公司的一些問題，但是為什么我們今天很多人都在談說，公司其實是沒有系統的，公司其實是沒有系統來支撐的。所以我再來看這件事情的話，我認為大家說其實在很多公司里面，它并不是沒有系統，大家也許只是說這些系統沒有去協同，沒有去協同作戰，系統之間彼此孤立，沒有總體設計，總體規劃，在用戶來看，你沒有完整的解決他核心的業務問題，最終他認為你一定是沒有系統的。
下面我就來跟大家分享我們是怎么解決這個問題的，在之前我們去檢討整個科沃斯內部的IT系統，差不多有三十多個，大大小小的。其實有一些可能不是系統，有一些就是一些小的功能。所以我在跟管理團隊，在作這些交流的時候，也談到說，實際上科沃斯缺少了一套骨架型的系統。所謂骨架型的系統，我打了一個比方，就如同是從蘇州到上海一樣，因為我們蘇州到上海中間的話會有一些沿線，我們沿線中間會有昆山、太倉，會有一些區域。我們到上海有兩種去法，第一種就是，直接有一條路從蘇州過去，大家把自己的一些核心的骨干型的路接到蘇州到上海這條高速公路上。第二種辦法就是大家各自修路，然后去從不同的地方去修到終點。這些所有的路之間，大家其實是不協同的，當然也有很多投入的浪費。所以我當時跟管理層講我們應該是需要一套骨架型的，一個核心的骨干線路。我認為這實際上就像我們蓋房子一樣，用戶的需求很多，我們也有一些小的應用或者小的功能，雖然當時IT技術比較薄弱，但實際上大家都是在點上對這些需求支撐的。蓋房子的時候，如果我們沒有骨架，用戶的各種大小需求來，其實是落不住的，最終這些需求都會掉下去，我們是希望解決骨架型的問題，必須搭一個骨架型的東西，然后用戶的需求，大的需求來會卡在一些地方，后面會用業務系統把它解決掉。同時每一個小的操作系統，來補充骨架系統，每個小的系統逐漸落實用戶需求，就會逐漸把整個房屋的屋頂補起來，最后用戶很小的需求也會被我們網住。我們在后面也提出了一些概念和想法，等下也會跟大家分享。
剛才我們前面談到一些基礎情況，包括基本性的思路，那在后面的話，也會談下基礎性的架構，我們是如何去應對這些問題的?？莆炙垢鷦e的企業不一樣，我們今天晚上主題也講到說，如何來看待互聯網下的科沃斯IT建設，可能恰恰跟很多企業不一樣的地方，就是我們有很大的電商，我們的產品是智慧化的，我們要用智慧化的導向，我們會有云，會有大數據，會有很多跟傳統企業不太一樣的地方。所以當時在系統建設的時候，我們有提出前中后臺的概念，所謂前中后臺，我想現在在很多企業里，包括很多外部咨詢公司也都在提，我在這邊也談談自己的一些基本的看法。
我們的前臺其實應該是特指銷售渠道，如果我要把他擴大的話應該是講，我們跟消費者相關的界面。因為渠道跟消費者接洽的應該有非常多的一些渠道，這些渠道又是千差萬別的，所以我們是希望在中臺里面，做去差異化的處理。在前臺到中臺之間，把差異化的問題處理掉，我們會統一對用戶的一些體驗。我們的后臺，應該是整個公司的大的運營支撐的系統，因為銷售模式可能變，業務模式也可以變，我們的溝通和很多玩法也可以變，但是涉及整個公司最核心的運營，我們的產品和服務品質不能變。所以我們在過去兩年的建設里面，都是在圍繞前中后臺，我們希望前臺是足夠的差異化，要匹配不同的銷售模型跟不同的人群，不同的消費者體驗，我們認為說，它要足夠接近用戶。所以我們提出我們的前臺要足夠輕，輕前臺，足夠可做到可插拔，確保所有的前臺，是可以做到足夠化的差異化，但是又足夠的切近消費者。同時，我們會有非常多的渠道系統，在前臺之后有非常多的渠道系統，去消除差異化。然后去統一到我們的中臺里面，我們的中臺里面會有統一訂單處理，然后同時會有統一的物流處理，包括統一會員。我們的會員應該叫社會化的CRM，這個跟傳統的CRMB2B的這種CRM還有些不一樣。所以我們在前臺去拿到足夠差異化的東西，去處理完以后，中臺會有統一的訂單履行，因為剛才談到，我們有非常多的銷售渠道，跟用戶去作關聯。我來了科沃斯以后，跟很多用戶也做過很多交流，在早期，我們大淘渠道的一些政策，可能是我在京東上是沒辦法享受，線上、線下也是有可能認為是不一樣的客戶。
所以，在前臺中臺把差異化做到足夠的消除之后，我們中臺的部分現在目前是非常完整的，我們是支撐了整個公司最核心的銷售業務。我們的中臺要面對非常多的銷售模式，有傳統銷售的，也有互聯網化的，訪問壓力也非常巨大，同時我們希望中臺又足夠的獨立。而不能說我們今天做了一個雙十一的促銷，然后去從前臺一路到中臺，然后去沖垮了我們的后臺，所以我們認為中臺要足夠的完整，完整的意義就是我們跟后端相對來說是可以脫離運行。我們是希望中臺足夠的重，足夠的完整。我們是重中臺的概念，同時希望我們的后臺是穩后臺，不要去經常變的，是我們最核心的業務，是我們最核心的流程。我們的后臺業務模式再變，但我核心的研發流程不變，生產流程不變，核心的工藝不變，自己的供應鏈不變。所以，我們提出后臺是穩后臺，我們的后臺是支撐公司長期發展得最核心的一條線。在過去通過非常多的一些項目來支撐前中后臺的落地建設。前臺部分，有官網商城，在實施官網商城的同時，也在SAP上線的時候也談到說我們要去做DIY，用戶可以去自己個性化定制產品需求，于是有我們DIY的模塊，然后從前臺到中臺到后臺，全線的去把它拉通。
DIY的業務應該也是這個時候包括了前中后臺，但是最主要體現在前臺，官網是我們自主開發的平臺，我們有一個官網團隊，現在也有自己的APP團隊，官網目前可能支撐到最高三百萬以上銷售額，這個也是我們的前臺。我們前臺同時也承接了生態圈建設，因為我們有非常多的渠道。所以，我們也希望在官網上承接，包括其他渠道的一些科沃斯粉絲，所以我們也是承接了一部分我們生態圈，包括我們會員的一些粉絲圈的建設。那這個部分的話也是在我們官網商城去呈現，是我們的前臺，剛才也談到說前臺其實是我們最貼近消費者的部分。
我們自己的超級APP，是移動互聯網的部分，這個當然也是前臺，還有微信平臺，我們要整合我們的公眾帳號，包括要去開微店，都是在我們微信平臺上跟用戶去做最直接的關聯。
我們的大中臺應該是跟我們官網商城同時建設的，在去年成功支撐了整個雙十一3.15個億的大促，幾乎整合了全部大淘分銷、線下官網國際，所有的渠道銷售，訂單處理、物流處理?，F在大中臺還在做線下門店的管理，就是一些日常性的管理。
我們的后臺是SAP ERP，應該是一個非常重要的項目，去年已經完全上線了。整體上應該來講，我們的官網商城是自己開發的，中臺也是自主開發的，后臺系統的話，最核心的就剛才講到骨架型的系統用到的SAP。SAP項目是從2014年的8月份開始，機器人板塊6個月上線，小家電板塊3個月上線。整個SAP很快就得到了穩定，目前的MRP準確率可以達到95%到98%。MES系統也是自己開發，現在已經推廣到所有的生產線，倉庫管理系統，包括我們內部的其他的一些系統，如供應商管理系統等，基本都是我們自主開發的，目前也都在實施。
實施大量系統的同時，還有對整個公司管理上一些結果的改善，就是如何去推動和協助公司管理層去看待整個公司的運營狀況?我們實施了敏捷BI，就是我們快速實施上線。我們剛才講了這么多的，其實就想講我們所有的項目也都是非常快速的。我一直對很多SAP實施的一些傳統方法論也有些看法，也跟很多公司做了不少交流，我認為，針對一些相對來說規模不大的企業，最好不要太多強調藍圖還有顧問咨詢的東西。更多的時候是要按照行業解決方案，按照一些模板，最佳實踐然后去分享給企業，去推薦給企業，讓企業先用起來，以后不斷迭代業務和系統的匹配，所以我們現在所有的系統都是在快速迭代的。
當然我們SAP應該也是經過了非常慘烈的1個月磨合期，但馬上過渡到穩定期，我們現有一個團隊專注于深化應用，同時在團隊配制上也會有與系統相關的業務改善人員。
剛才也談到，我剛剛來的時候其實基礎性的架構還是比較弱的，因為科沃斯在全球有很多業務，包括我們自己內部也有一些框架性和體系性的建設，都是比較薄弱的，所以，在過去非常迅速把整個通訊和數據，包括郵箱、溝通、知識庫管理做了快速部署。在整個協同方面，上了非常多的協同設備。我們的與德國，美國，日本分公司之間的MPLS網絡已經拉通?，F在在進行一個比較大的信息安全項目，科沃斯現在發展很快，來自于內外部的挑戰也很大，來自于外面的攻擊也很多，因此我們部署了專門的安全團隊，進行這個信息安全項目，希望集一張大網，把整個內外部的威脅隔離開，并保證官網的平穩運行。
針對云的建設，去年也做了一些規劃，針對科沃斯，在整個數據中心的設計上，我們會考慮混合云，把我們核心的互聯網應用，跟消費者相關的，都放在IDC里，把非常敏感的應用及數據放在本地。針對一些測試應用，包括海外應用，都會放在global的商業云上。IDC，本地還有整個商業云，我們都會做成混合云，它應該有非常完整的功能區分，這個部分我們正在實施。同時因為我們現在面臨的挑戰還比較大，還有518、618，還有雙十一，有非常多的一些促銷，希望未來的公有云，商業云，私有云，本地化之間都可以讓它們做很好的協同。
我們在IDC的核心互聯網應用其實是真正核心的生產力，但本地應該有它的一些備份，所以我們真正部署到IDC包括公有云上的應用，都會在本地去做一個業務備份。然后確保它是可以持續不間斷的運行。以上我簡單介紹了我們系統的一些情況，因為系統很多，每IT同時在運行的有10幾個項目，有很多項目其實都會拉到一年或者可能七八個月。所以，要在這么短的時間一一介紹還是比較困難的，還是簡單概要，讓大家了解科沃斯過去的兩年中我們大概做了一些什么。
最后，我會簡單再跟大家分享下，IT在科沃斯的定位，包括公司怎么看待IT。科沃斯是非常重視IT的，IT跟人力資源是整個發展的兩個輪子，我們最重要的戰略是產品。我剛加入科沃斯的時候，IT是跟我們產品并行的戰略。但我認為比較理性的應該是，IT是支撐的輪子。所以我剛來的時候，把IT做了一些定位，希望IT應該能更好的反映業務，我能確保正確的人，可以在正確的時間，通過正確的方式，可以拿到自己的一些被授權的的正確數據。但是后來又做了一些檢討和思考，我認為IT不是簡單的業務反映，我們本身就是業務。所以前段時間我跟經信委的領導報告時候說，IT本身就是business，當然很多人也在提IT就是business。科沃斯IT的電商平臺，本身就會直接產生生產力，官網本身就是銷售平臺，我們的中臺會直接一線支撐到大淘及所有渠道的銷售建設?，F在，大家可能用過我們的地寶產品，裝上配套的APP以后，可以在外面操控，確保它是可以及時去清掃，監督它的一些使用狀態，這個部分互聯網的研發就屬于IT團隊進行。在公司大生態圈建設中，我們有自己的移動互聯網建設，這個也是IT的主要工作，所以這一切貼近消費者的部分目前都是在IT負責，所以我認為，IT在科沃斯不是一個簡單的業務支撐部門，我們還可以說我們是個生產部門，未來應該是個非常核心的生產力部門。未來，我們還是有很多專家去支撐和引導到供應鏈及整個的生產和研發，所以，我認為說IT更是business，我們的終極目標是希望整個IT非常貼近業務或者就是業務，同時我們不是簡單的反應，我們是真正的業務的生產者，我們是生產力。
科沃斯目前的IT建設速度應該是比較快的，整體團隊將近80個人，電商技術團隊將近30多位，前一段時間我跟公司管理團隊交流的時候，也談到我們是希望電商技術部門未來就是公司的互聯網研發部門。這樣我們會讓整個電商團隊的功能更完整。因為現在電商團隊，面臨的不僅僅是公司銷售，還有自己的產品建設，還有內部基于互聯網的管理系統。所以，我們應該是公司互聯網化的很重要部分。同時，我們的運維叫系統運維，其實不是簡單的基礎運維，其中桌面運維團隊不光可以支撐基礎性的架構，也可以支撐SAP系統，支撐生產執行、倉儲、研發應用系統，甚至支撐電商系統。如果桌面運維有困難，可拋給二線團隊來處理，目前這個團隊應該有20多個人，除了桌面運維團隊，我們在架構，網絡，數據庫及SAPBasis等方面都有自己的專家隊伍，相對來說比我們一線的運維人員更多。系統運維團隊同時也承接了信息安全建設的部分，我認為在整個IT建設里面，所有的運維建設其實都是為信息安全服務的?；拘缘倪@種架構，其實也是穩定性也是信息安全的一部分，所以我們整個信息安全團隊，應該是比較整體面去看公司的信息化建設，去看我們整個運維的建設。
我們的應用部門叫持續改進部，我認為它應該不光具備一般系統建設的能力，它同時應該具備持續性的推動業務改進的能力，這個團隊目前有20人，承接SAP、生產、供應鏈、人事等大小系統，去年實施了整個SAP的建設，現在也同時在承接所有海外子公司的IT項目，另外它會承接我們內部很多職能部門的需求。還有一個很重要的，就是它會持續改進業務。
我們在今年也規劃了兩個團隊，一個大數據的團隊，這個團隊未來會關注在我們整個消費者數據，公司運營的數據，還有是我們自己的產品數據。我們的產品每天會運營非常多的一些數據，這些數據是我們未來最仰賴的最重要的資產。這個團隊不光要專注在整個技術的架構，同時要關注整個大數據的一些業務模型，通過數據去看業務，這個部門正在建設。我們還有一個業務規劃部門，因為我們IT有非常多的團隊，同時因為我們跟研發也有非常多的一些邊界去切割，大家之前在之前一些合作中雖然我們的邊界很清楚，但總體系統性的設計，包括系統性的架構還是不夠的。所以業務規劃部門會熟悉架構，統籌所有IT系統之間的架構設計，包括跟研發之間的一些互動跟架構設計，我們的邊界是清楚的，但架構是要協同的。我們最擔心的是，每個部門都在設計，但是最終，都是在解決點上或者局部的問題。
那我們現在的總體團隊，應該是這樣一個規模，團隊比較年輕，基本上都是在過去的兩年間來到科沃斯，很快變成了直接的生產力。所以我來客觀評價的話，團隊能力還比較弱，跟我們整個戰略還是相對不匹配的，人員的數量在一定程度解決了，但并沒有完全解決人員的效率和能力的問題。
現在IT業務規劃里面，還有一塊體系建設，它會去抓內部的執行標準，包括我們自己IT對外的一些SLA建設，那這個部分未來成熟的時候會推動到整個公司的其他體系部門，我們確保整個IT的體系建設，跟公司的業務是匹配的。那我們在業務規劃的人員配置上還會加入主導全局項目的項目經理，跟我們全局性的架構其實是一致的。因為我們有很多項目是跨團隊的，全局性的項目經理需要去解決團隊之間的資源協調。
以上大概是IT目前的情況，談到IT治理，我們現在推動的信息安全項目也是依據BS7799，去推動我們整個內部的體系建設的，同時整個系統運維的建設，也是比較偏向于用ITIL的方式，拆開一線跟二線的運維。IT內部管理已經有一個上線的系統，ITSM是我們自己開發的。還有個ITPM的項目正在實施。ITSM關注在日常服務，包括事件管理，交付，ITPM應該是關注在項目管理。兩個系統應該有整合，但又有一些職能的區分。ITSM，應該是偏向日常需求跟日常事件的管理，我們會從用戶的需求到交付，到我們中間跟用戶互動，用戶對我們的評價，各個環節都會監控，同時也會關注受理時間，響應時間，交付質量等方面。用戶會給受理人員打滿意度評分，我們也會給用戶打配合度評分。ITPM應該更多時候是把所有的項目做到統一的歸口管理，有一些比較大的項目，我們必須要去做模型區分，因為不是所有的項目，都是一個規模，一樣的要求。所以我們的ITPM應該更多的時候，關注項目的投入產出比，它到底是哪種業務模型的，對公司的貢獻到底是什么?它的每一個節點到底能不能控制?項目跟日常性的事務也是可以去做交換的，因為有些項目受理了以后，發現其實工作量很小，就可以轉到ITSM里面。當然ITSM中如果有些任務的工作量很大，那么就應該升級為整個項目的管理，我們會把它轉到ITPM中去，項目應該有管理機制，最終都會分解為每個人的基本任務。最近我們也在統計每個部門的服務工時，最終希望IT人員都可以體現出日常性的工時。
我們IT目前需求量為每個月2000多個，同時也有很多應用需求。目前ITSM系統整個公司都在用，我們也在公司的高層管理會上做過很多的推動，IT的KPI，包括系統穩定性，滿意度數據都是來自于這個系統，所以這個系統應該是針對我們日常性服務的監控，我認為基本性的能滿足我們的需求。
以上是我就科沃斯IT建設所做的一些簡單分享，基本上應該控制在一個小時內，看接下來大家有沒有什么問題。
互動答疑
提問：APP和微信端應用是否都需要?區別是什么?
回答：這個問題比較難，大家在整個生態圈的建設，包括移動互聯網，包括跟消費者去互動，相對來說都會面臨APP跟微信兩種模式，包括可能還有其他一些接入手段，在科沃斯，我認為兩個都是需要的，在科沃斯的話應該是不太一樣的，是因為我們整個產品都是用APP去操控的，這是第一點。
第二點，就是我們官網在上APP，包括我們的粉絲去協同APP著實解決體驗的問題。微信它有一個先天的優勢，就是不需要去安裝，比較輕，不用去太多的注冊，所以我認為在很多微信的互動跟溝通上，更多的時候可能還是以咨詢，或者就用戶去觀察為主，但是它是一個很重要的渠道，跟用戶去互動。所以，我們在微信平臺上更多的時候是關注在整個公眾號的管理，簡單一些部分去做微信，同時來考慮APP跟微信的平臺化，我們一定是要考慮如何去讓這些工具協同，如何去定位這些工具，這是一個相對開放式的問題，每一家使用的情況不一樣，我剛才講的應該是我對這個問題的一些思考。
提問：在需求變更管理上，您有什么經驗可以分享一下?
回答：談到需求變更的話，實際上我一直跟IT內部成員交流這些事情，我認為你讓用戶去不變更，其實是很難的。因為用戶他開始在很多時候，就不知道他真的想要什么，所以，我感覺應該是兩個解決方案：
第一個，就是應該業務先行，因為在系統的建設之前，業務到底是想要什么?在很多的時候，其實公司的IT建設，都是希望說通過IT建設來改變業務，但是業務反而不動。我認為說但凡是你系統比較穩定的，變更比較少的，往往都是在業務端已經相對穩定，它的需求也是相對來說比較清楚的。所以，它匹配系統功能還是比較清楚。另外一個，我認為談到用戶的需求，如果在需求的處理能力上有問題的話，也會跟用戶帶來困擾，用戶提了很多需求，我們自己沒有能力去消化，我們認為他提了個A，我們認為他真實的需求就是A。所以的話，我想最關鍵的話還是IT對需求把控的能力，要看到問題背后的問題。
我再延伸出來一點，剛才前面兩點可能是比較直接上看到的，但同時我認為，在對用戶的一些需求處理上，可能還真的是要來關注如何跟用戶去達成承諾?重要的需求是不是獲得了高層的一些認可，針對一些具體性需求。如權限，包括一些操作性需求，每個部門都是要來簽字確認的。在科沃斯內部，我們所有的需求，大家都達成了共識，需求的變更往往意味著有時候可能會有返工，那我們這些需求變更的話，都是要跟業務部門重新達成一致。目前我們并沒有用系統去管控，我認為，如何去發掘用戶真實的需求，這個更重要。
提問：BPM何時上為好?如何選型?
回答：大家問題比較多，我談一下BPM的事情，科沃斯也上了一套OA系統。這個OA實際上它更多的時候可能是一個集中的審批中心，但是實際上，會有一個問題，就是我們的集中審批一定是要跟非常多的系統和數據去做整合，提供足夠多的信息提供決策，當然我沒說我們現在的OA系統還是存在一些整合性上的能力問題，我只是想說BPM是非常重要的，但是科沃斯內部使用的還不好，我認為BPM可能還比一些核心的業務系統上線更重要。所以在我來看，就是我們要實施BPM的話，一定是要保證它有足夠靈活的接口，同時可以管問題，或者去管一些東西，管業務的一些東西要管得比較細，可以管到骨子里面去。我認為，BPM如果要做要早點做，如果傳統的公司相對來說規模不大，業務又不復雜的話，我認為OA是可以的。但是如果有太多業務的審批和流程的話，我建議要盡快實施BPM，同時要在各個系統中去操作，匯總到BPM里面去集中簽核。
提問：民營企業信息化的特點是要求高，時間短，包括費用有限又張做最全面的事，如何處理這方面的矛盾?
回答：我再談談要求高、時間短，包括資源有限，這個問題其實挺難解決的，因為任何事情其實都要平衡的。我們要來解決這些問題的話，就是我剛才講的一個解決方案，但是我同時還有另外一個補充，第一個就是，往往在面對這些要求高，時間短的要求時候，我們都很急，但是急的同時，有短期需求跟長期規劃的問題，或者有短期的矛盾跟長期的需求。如何去解決?我認為兩處都要抓，既要解決救火的問題，也要解決長期發展的問題，如果不救火這一把火可能燒的整個IT沒有辦法去生存，但是如果我們不解決長期的問題，每天都可能會在救火，所以我認為團隊的能力很重要，即使我們會借助外部的一些咨詢力量，也要保證我們可以去掌控核心需求。
第二個部分要補充的就是，談到企業的IT戰略，很多的人一直談到說我們要上什么系統?我們要做什么?實際上我認為應該來看很多咨詢公司怎么做這樣的規劃的，業務上要做什么?如果今天業務要做到100億，過百億的時候，我們必須有這么多支撐性的系統，所以老板看到超過100億，這些資源都會支持的，你如果說，你要簡單的建設系統，管理層一定會問你建設系統是做什么的?所以我們現在所有的IT系統其實都是從公司的戰略去分解過來的，所以在科沃斯這個問題不存在。但是同樣我認為，資源少、要求高這些都是存在的，當然我感覺最主要的就是來看你的執行能力怎么樣?我一直也跟團隊也在作交流，在這種環境下面，一定是要有很強的規劃能力，當然也要有很強的落地能力，再資源緊缺的情況下快速解決問題才是你的能力。
提問：雙十一3.15億，IT信息部門在這個過程中起到的作用?
回答：談到雙十一，IT的一些支撐，我經歷了科沃斯的兩次雙十一，2015,2016，每次都比較擔心，公司方面的壓力很大，為什么?因為整個雙十一還是以電商為主，跟IT是息息相關的，怎么講?2015年雙十一我和團隊在公司待了將近四十個小時。但是更重要的應該還是看平時，所以，我想談的另外一個就是，在雙十一這一天，IT要確保所有的線路都是有環路備份的;如果技術上解決不了的問題，業務上有沒有異地化的方案，甚至業務的客服人員要分成兩地辦公來解決集中化風險。同時我們要去擴充預算的一些接口容量，IT的系統要去做壓力測試，官網商城同時要做增強。這些部分，IT都是要來支撐的，所以在雙十一這一天，前端的銷售我們達成了多少億，但是其實最主要應該是IT的方方面面都在做支撐，IT的方方面面都在支撐這公司的全線建設，總之一點，應該是說，我們的基礎要把它做好，保障不出各種各樣的問題。
同時，我認為功夫在平時，把很多的壓力測試，包括一些工作做到位，來看我們如何去應對峰值。
提問：敏捷開發如何估算工作量?如何確保自己能在對應用部門的承諾時間內完成開發工作?
回答：剛才談到說如何去開發的時候，我們來估算我們的工作量，然后去確保在對應用部門的承諾時間里開發工作，我認為，這個事情其實是挺挑戰的，為什么?因為用戶的需求往往是希望你來做這件事情的時候立刻給他完成。所以我認為，第一個的話，相對評估自己的團隊的能力，是否能匹配到整個需求，在公司快速發展的過程中，我們的窗口期實際上是很小的，所以往往其實說一個月，其實有時候半個月系統就上線了，這是一塊。
第二塊，我們有戰略的產品經理，每個團隊都有自己的架構師去評工作量。面對用戶的很多開發功能需求上，我們都是評估自己的資源來排隊優先級，不是說所有的需求進來就會馬上都會去做。我們會確保團隊是高負荷的，但我們也會排出時間處理一些比較緊急的問題，比如平臺，網站，互聯網等。
關于這個問題，我自己的看法是，很多事情是平衡的，看你跟用戶怎么去溝通，敏捷開發如何去估算工作量?我認為讓它足夠的小，然后去輕裝上陣，可以很快的去行動，這個更重要。如果太大的話，其實我認為估算工作量都是有問題的。
提問：剛才您提到了很多信息團隊，我們現在團隊建設是怎樣進行的?如何與企業的業務戰略匹配?
回答：提到IT團隊的問題，就是我們現在每個團隊有自己的工程師，每個部門及部門下屬也有各自的架構，然后會有各個層次的leader。我對團隊一般還是盯在事情上的，我認為事情更重要，然后我們通過對事情對很多目標性的達成來推動團隊的建設。第二個的話，我們在項目執行中去磨合我們整個團隊。
談到與業務戰略匹配的問題，我認為說我是盯在戰略和業務上的，甚至唯業務中心論，也許短期內我們沒有辦法去精確的衡量我們跟業務戰略是匹配的，也許我們有時候會無法精確估計工作量，甚至某些方面資源可能過渡的投入，但實際上我們還是要來看業務上有沒有達成，業務目標達成了，資源的投入是有效的，如果沒達成，連資源的評估都是問題。
提問：敏捷開發用了docker技術嗎?
回答：敏捷開發沒有用，未來可能會用。
提問：您在公司推行ITIL的過程中遇到過什么困難，是怎么解決的?
回答：我們在公司推行ITIL的過程中還是有困難的，因為每個團隊不太一樣，電商有電商的風格，持續改進有持續改進的風格，系統運維也有系統運維的風格。所以目前整個思路是，體系的建設部分是抓大放小，重在執行，要確保盡快去解決問題。其實有很多體系性的東西，往往壓力不在規劃上，而是在短期內沒有結果上。困難一定是有的，因為你把規定定起來，效率不一定會有那么高，會有困難，但是我認為這個事情，就是要來解決的。
提問：如何管理您手下的技術牛人，減小離職率?
回答：牛人的管理我認為也很難解決，因為現在整個互聯網人才，包括各個企業其實大家都在搶，所以我們還是比較建議如果是互聯網團隊，就按互聯網團隊的方式去運作，每一個團隊保證它足夠的彈性。如果是牛人的話，讓他有足夠的成長空間。
