“曉”說運營商核心能力掌控之路

shsnchyw發表於2014-12-30

前言:作者王曉徵,浙江移動資訊科技部總經理助理。作者對運營商核心能力掌控、去IOE、技術架構管控等均有鮮明獨到的觀點,“曉”說自成一家,供大家閱讀。(本文轉自“新炬網路”微信公眾號)


《運營商去O之我見》發表之後,轉載和反響有點熱烈,很多朋友提出來很多積極誠懇的意見和建議,在這裡謝謝大家了。本人才疏學淺,拋磚引玉,能引起大家的思考,感到非常榮幸。


《運營商去O之我見》的文章中我提到了運營商核心技術力量弱,核心能力掌控缺失的現狀。這種情況對於去O來說造成了一定的困擾。這個問題究竟是如何形成的?又該如何解決呢?這個問題說起來比較大,我姑且簡單說幾句吧。


國有傳統企業自身體制和機制的限制,是導致問題出現的直接原因。簡而言之,內部重業務輕技術,重專案輕運營,重彙報輕實幹,重管控輕創新的機制終於還是佔了統治地位。


當年某動剛成立的時候,機制一度有市場化的雛形,有些激勵機制今天看來仍然不過時,有些做法現在看起來很懷念!這是最好的時代,這也是最壞的時代!這句話我在最近我們內部一篇大資料培訓的材料中看到過,我覺得用在十來年前世紀交替之際的運營商也是蠻貼切的。那個時代遺留下來的一些好的遺產,一直給我們提供正能量到今天。


舉個例子,那時候我們一度自己開發軟體,一度擁有技術人員的培養和技術支援的機制,可惜最終由於種種原因,沒有堅持發展下去,中道崩殂了。當年也有過所謂的大H技術通道,但是搞得不徹底,沿用了管理幹部競聘那套做法,真正的技術人員對那套充斥著管理思路,業務思路和PPT文化的技術通道很不感冒,最終還是演變成了資深員工和退居二線幹部的通道,應該說這個機制對企業的發展仍然是有正能量的,但對設立它的初衷就大相徑庭了。當年考慮的開發外包,也不能說就是錯誤的,在當時,在當年,不失為一個實事求是的,快速上手的,抓大放小的創新方式,問題在於後面沒有持續演化下去!


今天我們IT部門的員工比當年多了幾倍,但是我們大多數員工的工作重心都是業務,管理和日常性事物,典型的例子是萬惡的PPT,這個大家都懂的......在技術上面的投入實質上非常有限,這直接導致了後繼無人的危險!


現在遺留下來的碩果僅存的技術骨幹和一批懂技術的幹部,大多數是那個時代的遺產。運營商最後技術力量,就像沙漠裡面的小草,就像突破三道封鎖線走過草地雪山的紅軍,很多人離開了這個戰線,人數銳減,剩下的人大浪淘沙,幾經起伏,幾度風雨,到今天仍然頑強地生存著。


但就像我在前兩篇裡面說的,目前我們自身的力量並不強大,太多的人流失了,今天我們在技術架構方面相對還有一點力量,但資料架構和應用架構(具體說是邏輯架構)則成了阿基里斯之踝!再說具體點,我們運營商可以自己不生產伺服器和資料庫,不開發應用,但是不能不掌握架構,不應該出現對任何一個層面的供應商出現過度依賴乃至近乎壟斷的情況!從這個角度說,應用開發商是運營商IT技術方面最大的管理痛點,我們今天可以換網路裝置廠家,換伺服器廠家,甚至連適度去O也不是完全沒有可能,但誰敢說我已經能夠在核心應用開發的合作伙伴方面形成真正的競爭?全運營商行業我看都沒有!(如果哪家運營商省級以上單位已經完全具備此能力,我一定虛心學習先進經驗)運營商與合作伙伴應該是互相促進共同發展的關係,絕不應該形成對供應商的過度依賴,這也是運營商核心能力掌控應該達到的及格線。不幸的是至少在部分領域並沒有達標。


我看過銀行的架構管控思路,銀行的看法就是掌握架構不等於不用進口用國產,簡單地使用國內的軟硬體產品並不能達到自主可控的目標,特別是在當前市場化和資本運作的大環境下,企業的國內外資本性質轉換很快,所謂的國內和國外都是相對的,這方面市場上已經有了很多實際的案例。


銀行提出的是“自主可控”研發,在滿足甲方自身資訊系統整體體系架構的前提下,自主研發核心和關鍵資訊系統,並分層異構使用外部產品,實現對資訊科技風險的可監控、可管理、過程可審計。簡而言之,八個字,自主可控,分層異構。這個我以為很值得我們運營商的技術管理人去思考和借鑑。


今天,在我們大談去IOE的時候,儘管我想出了各種各樣的現實應對之策,但歸根到底,自身技術力量的發展最後是繞不過去的,所以,必須找出運營商特色的核心能力掌控之道,換句話說的直白點就是如何加強對開發商的管控能力!我提出兩手抓,兩手都要硬的應對思路。


首先,必須從現在開始,總結得失,採取有效措施,奮起直追,培養積聚運營商自己的技術力量。這個我想來想去還是覺得是繞不過去。運營商之大,難道真的容不下技術人員的一張辦公桌?不信,不甘心,要推動!此外,移動網際網路時代,技術發展很快。傳統的IOE技術架構正在逐漸演化為新一代以X86,快閃記憶體,開源應用平臺,資料平臺等技術為基礎的新一代技術架構,站更高一點看,傳統的IT正在向DT演進,在半個月之前,阿里巴巴董事局主席馬雲在內部郵件中提出,要在未來十年建立DT資料時代中國商業發展的基礎設施。有的時候昨天的好就是今天的短,反之亦然。今天大家在一個起跑線上。IT和DT之間,不僅僅是一個技術的變革,而是思想意識的變革,IT主要是為我服務,用我來更好的控制和管理,DT是啟用生產力,讓別人活得比你好,DT的思想是相信別人比你聰明,IT的思想是我比你有能力,因為我掌握資訊,你不掌握。所以,我們在這個時代,幾乎大家是同一起跑線。所以,昨天運營商技術團隊落後了,但今天我們有機會大破大立,創造後發優勢。而且,運營商根本不需要去過度創新,不要去做第一名。木秀於林風必催之,做技術老大代價是很高的,運營商只要跟在網際網路行業後面,學習吸收,批判接收就可以了,而這是很有利的發展條件。當然,我希望我們現在就行動,不要再拖下去拖到技術團隊衰弱到連學習抄襲的能力都喪失了,那樣就太可悲了。


具體做什麼?


一、培養文化,尊重技術


在一些領導和管理部門或業務部門的員工看來,技術人員往往像是生活在另一個世界的科學怪人,他們不善言辭,脾氣古怪,每次交流都是語言不詳,每次彙報就是叫苦加要資源。而技術人員反過來看也是一樣,我辛辛苦苦加班加點,你又未必懂我的專業你知道我有多苦嗎?你知道我的價值嗎?你聽得懂我在說什麼嗎?於是,溝通不暢開始了,抱怨開始了,資訊不對稱開始了,甚至人才流失開始了。尤其是在運營商這種體制下,業務性型人員提拔的機率遠大於技術型人員,再加上技術通道的不暢,造成技術人員價值和成就感得到滿足的機率不高(有些技術人的心態是我不求工資有多高,但求被認可、被尊重總不過分吧 ),進一步加劇了這種情況的蔓延。


首先還是呼籲一下,請各級領導,管理部門和業務部門的員工尊重技術人員。請至少能夠嘗試去傾聽他們,去理解他們,不要輕易對他們呼來喝去,指手畫腳。只要這麼去做了,就算僅僅是一個形式,技術人員也會感到溫暖。知道嗎,據說某位運營商員工去阿里的真正原因還真不一定是為了錢,而是感到業務部門的員工往往只知道做二傳手,一個業務需求看都不看就往他手裡扔,態度稍有怠慢就去領導那裡投訴,這種得不到尊重得不到理解的感覺對技術人員的打擊才是非常致命的。看上去這段很虛,但我還是要放在第一點來提。


要改進這一點其實真沒什麼投入,一方面只要省公司以上領導發言的時候有關尊重技術的話多說幾句,多說幾次就可以了,第二點就是要把中央八項規定落到實處,尤其是第二,第三條。我在這裡抄錄一下:第二條、要精簡會議活動,切實改進會風,提高會議實效,開短會、講短話,力戒空話、套話。第三條、要精簡檔案簡報,切實改進文風,沒有實質內容、可發可不發的檔案、簡報一律不發。第三點針對運營商還要加上一條,去PPT!對於運營商來說,去PPT比去IOE重要多了。當然我這個去不是說機械地不準用,而是不要濫用PPT,一切以效率出發,能脫稿的儘量脫稿,能用word的儘量不用PPT。讓我們的員工從文山會海中脫離出來,把時間,把生命都燃燒在真正產生價值的事情中去,找回世紀之交那種高效務實的作風來!


二、反思自己,創造價值


一個巴掌拍不響,運營商的技術人自己也要反思。難道技術人就沒有責任了?甲午戰爭大家都在反思清政府腐敗,難道海軍就可以免責了?說到底戰爭勝負還是一線官兵打出來的。韓國足球隊再買通裁判,也得自己過硬,中國隊就算有了裁判,就能進世界盃四強了?扯遠了,打住......


運營商的技術人能否提升自身水平,能否以業務價值的視角來看問題,能否在日常工作中找到自己新的定位,新的地位?網際網路公司也不是在技術線上白白燒錢,人家也要看到價值的。技術人員們請捫心自問,如果公司現在給技術線加大投入,技術線能給出什麼樣的面向業務價值的KPI?其實不要去叫苦,環境現在確實不給力,但是我希望要麼閉嘴,要麼走人,要麼推動,三者必居其一,叫苦不是一個可以接受的選項,必須奮進,必須提升自身能力,改變形象,必須有為公司創造出價值的決心和意識。


下面簡單舉幾個例子。


價值一:業務價值。大資料時代了,透過什麼樣的技術創新,技術團隊能夠像網際網路企業那樣,為公司的決策提供有效支援,為公司的營銷提供高效低成本的方案?我們的線上渠道什麼時候可以取代實體渠道,成為公司營銷的主力?這些方面,我們的技術人能做什麼?


價值二:管理價值。我們的系統能不能真正提高生產者的效能,成為公司使用我們的it系統的員工工作上的大殺器?網際網路企業提把客戶感知做到極致,我們能不能多少也提一點?也做到一點?這些方面,運營商的技術團隊能做什麼?


價值三:經濟價值。我們的支撐,網路,ICT系統大量使用傳統的IOE架構,投資和成本居高不下,在技術架構演講,為公司節省投資和成本方面,運營商的技術團隊能做什麼?


三、創造機制,培養隊伍


終於談到最關鍵的一點,運營商需要有能留住技術人才的機制,運營商的人力資源管理體系必須改革!


上面談到過現行的大H體系名存實亡的現實,但是相信運營商的高層已經認識到了問題,相信運營商的人力資源管理部門不乏有識之士,只要有相關領導和部門的理解支援,這個問題一定能夠解決,至少能夠緩解。


我建議注意幾點。


首先,必須有一個大H的准入範圍管理,不能什麼都往裡面裝,否則又走上老路了。必須限制範圍,真正聚焦到那些真正的稀缺崗位,高價值崗位,專業性崗位。


其次,必須考慮一個合理的評價機制。現在的技術通道競聘,評委大多是非技術部門中層和公司高層,加上真正的技術人員往往拙於言辭和PPT,在這種面試中脫穎而出的往往是適合M線的人。建議在形式上做出最佳化,增加客觀分的比例,增加與其真正接觸的員工領導的打分比重。


此外,建議加強人力資源部門的團隊建設,運營商的人力資源部應該真正成為公司最重要的部門,具備對各類人才包括技術人才全面的評估能力。短期內,可以採取與技術部門合作的方式來治標,可以出具臨時性的技術人才評定和激勵方案,中期可以引入第三方專業的諮詢公司,阿里就是這麼做的,也就幾十萬上百萬,只要真正做好方案,這點成本算的了什麼?遠期就是看人力資源部自身建設了......


四、找準方向,重點突破


應用架構和資料架構是目前運營商核心能力掌控最大的攔路虎。應用架構(以及邏輯架構)關注系統總體功能和業務邏輯設計、系統內部和系統之間的介面設計;資料架構關注後設資料、資料儲存、資料分佈、資料模型、資料質量、資料生命週期、資料資產、資料同步等。只要在這兩點上入手,必會收到滿意的效果。這個前面多次提到了,不多說了。這兩個方向就是我們的重點突破口!


如何去做呢?如何才能重拾舊山河,加強開發商管控,培養運營商自己的技術力量呢?


我先打個比方,講個故事。從前有個老皇帝,他一手打下江山,能力超強,他可以每天工作十幾個小時,他可以不要宰相,事必躬親,於是朝政一片清明。很多年後老皇帝退了,新皇帝繼位,新皇帝的能力遠不如老皇帝,於是新皇帝設立了宰相,幫他管理朝政。一開始,一切太平,可是隨著時間的推移,由於宰相才是天天接觸日常具體政務的人,宰相權威日盛,新皇帝每天工作是輕鬆,但是漸漸覺得駕馭不了宰相,朝政有失控的風險。皇上急了,他貶斥了宰相,自己來抓朝政,可是宰相一休息,沒打過江山的新皇上每天面對堆積如山的公文,幾天就形容枯槁,幾近奔潰了,沒法子,又把宰相請回來,於是宰相上班了,朝政正常了,宰相地位更高了。這該咋辦啊。事實上,宰相僅僅是文官集團的代言人,皇帝想以一己之力對付整個文官集團,除非是打江山的老皇上,新皇上確實是力有不逮啊!終於有一天,皇上靈機一動,終於想出來辦法。


對策一,釜底抽薪。皇帝最不缺的就是太監。給太監學文化,以文化太監隊伍為基礎,組建內廷,組建東廠。從此,外廷宰相和文官集團的公文,必須有內廷太監的確認才能執行,外廷和內廷互相鉗制,東廠還時不時對文官集團的內部情況進行勘察彙報,皇上耳清目明,訊息靈通,居中協調,倍感輕鬆。


對策二,分而治之。你宰相不是能嗎,你文官集團不是鐵板一塊嗎?皇上自從有了內廷和東廠,對文官集團的影響力大了,於是進一步推進了官職改革,把原來宰相自己設計的鐵板一塊的官職,改成了標準化規範化的三省六部,各省各部之間職責清楚,分工配合,但各自又自成一系,於是,宰相就更不能一手遮天了。同時,皇上還委派自己的皇室青年子弟,成立錦衣衛與東廠一起工作,這樣的體制成立之後,新皇帝終於可以穩坐江山了。


大家可能看出來了,老皇帝和新皇帝就是不同階段的運營商IT部門,宰相就是核心應用開發商,文官集團就是應用架構,內廷和東廠就是獨立第三方合作伙伴,皇室青年子弟掌管的錦衣衛就是局方自己的新一代技術人員,公文就是資料架構。


局方現狀是技術團隊實力凋零,對開發商依賴嚴重,暫時自己的技術力量還需要慢慢培養,暫時還不堪大用。因此,我們完全可以投入自己的局方人員,可以以老帶新,力量不足的話再加第三方合作伙伴人員,透過SOA架構體系的建設,逐步理清應用之間的介面,相信掌控介面只是時間問題。等到瓜熟蒂落,水到渠成的那一天,我們真正地掌握了介面,把核心系統進行合理的拆分,至少要把現在動不動就是CRm、BOSS這樣的巨無霸系統大卸八塊。任何系統拆細了還能翻起什麼浪花來啊?


此外,資料架構是另一條獨立戰線,套路也差不多。透過有實力的第三方合作伙伴,我們完全可以從資料架構稽核入手,逐步推進,逐步培養,逐步延伸到資料架構設計。在這個過程中,局方可以逐步培養出自己新一代的資料架構技術人才。具體工作開展可以以先核心系統後外圍系統,先稽核後設計,先流程後工具,先表明後深入為原則逐步推進。這樣也就達到了初步的核心能力掌控的目的,對開發商也就具備了初具規模的掌控能力。


透過以上措施,運營商完全可能挽狂瀾於既倒,一方面迅速形成生產力,一方面逐步推進,一方面逐步培育出自己的新一代技術力量。這就是堂堂正正的陽謀,正大光明,穩健而堅定。


當然,和一些兄弟研討後,我覺得,以上方案有幾個地方也可能是有一定的侷限性的。


首先,對合作夥伴的管理是需要成本的,運營商現在的合作伙伴數量已經不少了,再引入新的合作伙伴對運營商的管理能力是一個挑戰。


其次,運營商現在沒有明確清晰統一的的業務架構和產品架構管理體系,很多職能都分散在各個業務部門,業務部門之間的溝通和資訊互動機制也有值得提升之處,俗話說,上樑不正下樑歪,業務和產品沒管清楚一定害了需求開發,需求開發出了漏洞一定影響到執行運維......這給it部門構成了很大的壓力,其中首當其衝的就是IT部門的需求管理員。現在的需求管理員對外要成為使能者,多少要幫助業務部門做好業務、需求,產品的梳理,需求實現的必要性和效能的分析,對內要做好需求分析和設計,壓力是非常大的,在目前的體制下也缺乏有效的激勵機制,對這個團隊的發展造成了一定的困擾。而對於這個團隊,很多工作都是難以找到也不適合交給第三方合作伙伴的。所以上述思路中對於獨立第三方合作伙伴使用的適用範圍是有一定的限制的,只能在技術架構和部分的資料架構、應用架構、邏輯架構的範圍內起到一定的作用,不能面面俱到包治百病。


如果這樣,或許可以這樣搞:抽調精銳部隊,集中兵力打殲滅戰。抽調局方精幹力量到需求管理員團隊,把這塊工作先頂起來,確保頂層建設不走偏。其他各條戰線,還是走我上文中的路線,獨立第三方+局方新生力量兩手抓,互相配合,共同發展。或許如此可行?


暫時就寫這麼多,本人才疏學淺,分析得不一定全面,時間也比較倉促,很多觀點一定是值得商榷的,還希望大家批評指正。如果能透過本文引出大家的討論,能夠為運營商核心技術力量的培育,核心能力的掌控引出一條真正可操作的路線,我就深感欣慰了。


最後補充一句,我和很多合作伙伴的具體技術人員,管理人員合作都十分融洽,我對任何合作伙伴都沒有什麼偏見,以上分析純屬就事論事,而且我相信一個技術強大的甲方才能促進乙方的不斷成長,希望透過大家的共同努力,推動整個生態環境的持續良性發展,謝謝大家!

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29960155/viewspace-1385363/,如需轉載,請註明出處,否則將追究法律責任。

相關文章