電信運營商數(shù)字化轉(zhuǎn)型戰(zhàn)略調(diào)查—2021

引言

電信運營商(CSP)面臨轉(zhuǎn)型為數(shù)字服務(wù)提供商的巨大壓力；為了實現(xiàn)這一目標(biāo)，它們正在推行數(shù)字化轉(zhuǎn)型戰(zhàn)略。Omdia將數(shù)字化轉(zhuǎn)型定義為采用、部署數(shù)字技術(shù)，以便與其它數(shù)字公司競爭/合作，并支持新商業(yè)模式的重大轉(zhuǎn)型過程。它是一場多維度的變革，影響到CSP的方方面面，包括客戶互動、運營流程、網(wǎng)絡(luò)、技術(shù)、架構(gòu)、組織文化和員工。數(shù)字化轉(zhuǎn)型是一個持續(xù)演進(jìn)的過程，并不會休止。為了深入了解這一過程，Omdia對電信運營商的數(shù)字化轉(zhuǎn)型戰(zhàn)略進(jìn)行了調(diào)查。

1 報告摘要

數(shù)字化轉(zhuǎn)型是CSP的一項重要任務(wù)，絕大多數(shù)受訪者聲稱所有或部分業(yè)務(wù)領(lǐng)域都在推進(jìn)數(shù)字化轉(zhuǎn)型。盡管受到新冠疫情影響，三分之二的CSP稱數(shù)字化轉(zhuǎn)型在繼續(xù)穩(wěn)步推進(jìn)，另有25%稱數(shù)字化轉(zhuǎn)型正在加速。CSP的前三大數(shù)字化轉(zhuǎn)型項目包括使用基于云的模型來提高敏捷性、規(guī)模和效率，創(chuàng)建一個以數(shù)據(jù)為中心的組織，以及使用開放API來使系統(tǒng)集成和交互操作變得更容易。如果深入到具體的項目，會呈現(xiàn)出更微妙的畫面。從這項調(diào)查可以清楚地看出，CSP并不缺乏雄心壯志。

云計算和邊緣計算以及開放API被認(rèn)為最重要的兩種使能技術(shù)。CSP在采用DevOps和敏捷工具/方法以及可伸縮的敏捷框架方面也取得了進(jìn)展。

超大規(guī)模公司變得越來越重要，不僅可以促進(jìn)CSP數(shù)字化轉(zhuǎn)型，還可以成為CSP親密的戰(zhàn)略合作伙伴。

對于數(shù)字化轉(zhuǎn)型，不需要在“漸進(jìn)式”和“爆炸式”這兩種方式之間做出選擇。敏捷方法越來越多地支持大范圍的轉(zhuǎn)型，但這種轉(zhuǎn)型快速、普遍且自下而上(而不是整體僵化、自上而下的轉(zhuǎn)型)。

2 調(diào)查內(nèi)容及結(jié)果

2.1 數(shù)字化轉(zhuǎn)型進(jìn)展相對順利

調(diào)查顯示，82%的受訪者聲稱所有或部分業(yè)務(wù)領(lǐng)域都在推進(jìn)數(shù)字化轉(zhuǎn)型。

圖1 企業(yè)數(shù)字化轉(zhuǎn)型的總體進(jìn)展

如圖1所示，各個地區(qū)存在一些差異——北美CSP的數(shù)字化轉(zhuǎn)型要領(lǐng)先一步。移動運營商通常也走在前面。但不同的工作職能或部門之間并沒有明顯的區(qū)別，考慮到數(shù)字化轉(zhuǎn)型舉措日益普及的本質(zhì)，這種情況并不令人意外。

2.2 數(shù)字化轉(zhuǎn)型穩(wěn)步推進(jìn)

63%的CSP持續(xù)穩(wěn)步推進(jìn)數(shù)字化轉(zhuǎn)型，25%加快了數(shù)字化轉(zhuǎn)型步伐。只有8%的CSP表示轉(zhuǎn)型速度放緩，4%承認(rèn)停滯或倒退。

這表明，數(shù)字化轉(zhuǎn)型并未因疫情影響而脫軌；但同樣的，CSP推進(jìn)數(shù)字化項目的速度趨于穩(wěn)定(而不是迅速加速)。

CSP對于這個問題的回答與上一個問題的答案非常吻合——上一題中有82%的CSP表示所有或某些業(yè)務(wù)領(lǐng)域順利推進(jìn)數(shù)字化轉(zhuǎn)型，這種吻合的情況與我們在之前Omdia調(diào)查中看到的情況非常相似。

值得注意的是，中歐/東歐的CSP最有可能承認(rèn)數(shù)字化轉(zhuǎn)型放緩或倒退。不過，考慮到樣本量很小，我們可能不應(yīng)該過多解讀這一點。

2.3 首席技術(shù)官(CTO)帶頭推進(jìn)數(shù)字化轉(zhuǎn)型戰(zhàn)略

42%的受訪者表示CTO在引領(lǐng)數(shù)字化轉(zhuǎn)型戰(zhàn)略。這可能是對實際情況的準(zhǔn)確反映(無關(guān)誰回答了這個問題)，因為我們的調(diào)查對象相當(dāng)平均地來自網(wǎng)絡(luò)和IT部門。一旦加入首席信息官(CIO)和首席技術(shù)創(chuàng)新官 (CTIO)等職能，這三個角色就占到了數(shù)字化轉(zhuǎn)型領(lǐng)導(dǎo)崗位的62%。

顯然，技術(shù)職能仍然占據(jù)主導(dǎo)地位。這些年來，跨小組管理職能沒有取得多少進(jìn)展。

首席數(shù)字官發(fā)揮的作用也顯著增加。與之前的調(diào)查相比，另一個不同之處在于，聲稱首席執(zhí)行官(CEO)領(lǐng)導(dǎo)這類舉措的受訪者減少。這可能是市場日益成熟的結(jié)果，CEO不再需要強行推行激進(jìn)的變革。但在數(shù)字化轉(zhuǎn)型過程中，采用一種過于封閉的方式也存在潛在的缺陷。

2.4 數(shù)字化轉(zhuǎn)型方面的支出

如圖2所示，大多數(shù)CSP(60%)聲稱通常劃撥11~15%或16~20%的資本支出支持?jǐn)?shù)字化轉(zhuǎn)型項目。這些數(shù)字比我們之前看到的要高。

2020年，數(shù)字化轉(zhuǎn)型總體預(yù)算保持不變(55%)，不過有36%的CSP增加了數(shù)字化轉(zhuǎn)型預(yù)算。到2021年，這方面的預(yù)算預(yù)計將增加(49%)。

圖2 2020年資本支出(CAPEX)中用于支持?jǐn)?shù)字化轉(zhuǎn)型項目的比例

2.5 改變客戶體驗，更快地提供新服務(wù)

“改變客戶體驗并增強關(guān)系”是CSP推進(jìn)數(shù)字化轉(zhuǎn)型的最大動力。

對CSP來說，客戶體驗很重要，但新冠疫情給客戶互動帶來了重大影響，促使CSP快速擁抱數(shù)字渠道。與此同時，更好地協(xié)調(diào)客戶體驗和交付全渠道體驗的壓力越來越大。那些提供不完整客戶體驗的CSP很難贏得新客戶。

其它關(guān)鍵驅(qū)動因素包括創(chuàng)造新的數(shù)字收入流、更快地推出產(chǎn)品和服務(wù)，以及實現(xiàn)業(yè)務(wù)敏捷性來支持這些目標(biāo)達(dá)成。這些驅(qū)動因素推動CSP投資人工智能(AI)支持的自動化、改進(jìn)的服務(wù)和網(wǎng)絡(luò)管理功能、敏捷盈利工具以及基于云的交付模型。

節(jié)約資本支出排在很后面，這并不是因為CSP不需要追求資本支出效率，而是因為只有采取攻勢并創(chuàng)造新的收入來源，它們才能生存下來。

2.6 傳統(tǒng)組織結(jié)構(gòu)是轉(zhuǎn)型之前的主要障礙

CSP在嘗試數(shù)字化轉(zhuǎn)型之前面臨的主要障礙仍然來自組織層面(傳統(tǒng)組織架構(gòu)或封閉式結(jié)構(gòu))?，F(xiàn)有產(chǎn)品組合和流程的復(fù)雜性也是一個重要因素。令人驚訝的是，在這個階段，CSP并不認(rèn)為缺乏IT技能是一個很大的障礙。這與轉(zhuǎn)型項目真正實施后這個問題所造成的重大障礙形成了鮮明對比。

有限的內(nèi)部IT專業(yè)知識和監(jiān)管制約是CSP實施數(shù)字化轉(zhuǎn)型所面臨的兩大挑戰(zhàn)。有限的內(nèi)部IT專業(yè)知識經(jīng)常被認(rèn)為是云遷移面臨的一個主要挑戰(zhàn)，特別是缺乏相關(guān)技能來擁抱容器化和微服務(wù)架構(gòu)以及敏捷DevOps和CI/CD實踐。此外，正如我們將在稍后的調(diào)查中看到的那樣，CSP在多個領(lǐng)域都面臨技能短缺的問題。監(jiān)管方面的問題包括數(shù)據(jù)安全、隱私、信任問題，以及傳統(tǒng)運營商不得不面對的許多監(jiān)管限制，但這些限制不適用于大型互聯(lián)網(wǎng)公司和其它行業(yè)顛覆者。

2.7 創(chuàng)造基于云、以數(shù)據(jù)為中心的開放組織

如圖3所示，在這次調(diào)查中，CSP列舉了三大重要措施：使用基于云的模型來提升敏捷性、規(guī)模和效率；創(chuàng)造以數(shù)據(jù)為中心的組織；使用開放API來使系統(tǒng)集成和交互操作變得更容易。

CSP越來越重視基于云的模型，這是因為提振敏捷性、自動化、可伸縮性和效率能夠帶來好處。成為一個以數(shù)據(jù)為中心的組織能夠帶來競爭優(yōu)勢，但它的意義要深遠(yuǎn)得多，因為CSP只有具備所需的AI和數(shù)據(jù)管理功能才能實現(xiàn)圖3中列出的大多數(shù)轉(zhuǎn)型目標(biāo)。開放API為其它許多措施提供支撐，這是TM論壇關(guān)注開放API的原因之一，也是我們看到CSP認(rèn)真對待開放API的原因之一。

采用平臺商業(yè)模式只排在中間位置，考慮到它在戰(zhàn)略層面的重要性，這一結(jié)果令人失望。利用技術(shù)來實現(xiàn)更高的敏捷性、效率和開放性非常好；但對CSP來說，要實現(xiàn)數(shù)字化轉(zhuǎn)型，還必須利用技術(shù)作為平臺商業(yè)模式的敲門磚。

圖3 組織進(jìn)行數(shù)字化轉(zhuǎn)型的動機

2.8 基于云的技術(shù)是關(guān)鍵

如圖4所示，云計算和邊緣計算被認(rèn)為是最重要的兩種使能技術(shù)。

CSP向云遷移已經(jīng)有一段時間了,但除此之外，我們現(xiàn)在還可以預(yù)計5G驅(qū)動的邊緣投資增多,這主要是為了滿足新的消費者/企業(yè)服務(wù)的低延遲需求——主要圍繞視頻、游戲服務(wù)以及大量物聯(lián)網(wǎng)、專網(wǎng)和垂直行業(yè)用例。

對云遷移的關(guān)注，以及最近對邊緣云的投資熱潮，也導(dǎo)致CSP、供應(yīng)商和大型云提供商之間越來越多的合作和競爭。AWS等云服務(wù)提供商與C S P 密切合作，協(xié)助IT和電信云轉(zhuǎn)型以及客戶體驗項目，以及實現(xiàn)上述目標(biāo)所需的支持系統(tǒng)變更。

平臺驅(qū)動的架構(gòu)和開放API也是關(guān)鍵要素，旨在實現(xiàn)無障礙的集成、提高創(chuàng)新性和競爭性，同時為更復(fù)雜的網(wǎng)絡(luò)/IT生態(tài)和合作伙伴戰(zhàn)略賦能。這也是更廣泛的OSS轉(zhuǎn)型的一部分。

最后一點很明確，區(qū)塊鏈排名靠后表明，在擴展互連和結(jié)算流程用例失敗之后，電信運營商仍在尋找殺手級應(yīng)用。

圖4 數(shù)字化轉(zhuǎn)型最重要的賦能技術(shù)

2.9 CSP在采用敏捷/DevOps工具和方法以及開放API方面取得了很大進(jìn)展

CSP似乎在廣泛采用DevOps/敏捷工具和方法，這意味著很大的進(jìn)步，因為之前的Omdia研究表明大多數(shù)運營商在這方面仍然滯后。此次調(diào)查顯示，大約有三分之一的CSP現(xiàn)在已經(jīng)順利地推進(jìn)實施，而且有更多CSP處于早期規(guī)劃階段。開放API的采用也進(jìn)展良好。

而在其它領(lǐng)域，如TM論壇的ODA(開放數(shù)字架構(gòu))標(biāo)準(zhǔn)化倡議，采用程度則要低得多。這并不意味著該倡議沒有得到業(yè)界的大力支持，而是實施仍處于初期階段，而且可能需要更多的供應(yīng)商支持。受訪者對低代碼和無代碼IT解決方案的采用程度最低。

與其它行業(yè)一樣，電信行業(yè)也越來越多地采用敏捷方法。第一代敏捷方法主要專屬于小型團(tuán)隊，但為了管理大型項目和多個團(tuán)隊，有必要采用敏捷擴展模型。在這個問題中，我們詢問CSP正在實施或計劃實施哪些敏捷擴展框架。

結(jié)果表明，在我們調(diào)查的CSP中，SAFe(可擴展敏捷框架)和LeSS(大規(guī)模Scrum)是最常用的敏捷模型。這也許并不奇怪，因為Omdia之前已經(jīng)提到過SAFe等框架的好處。Spotify模式也有支持者。但更有趣的是，CSP正在探索幾乎所有的框架，沒有實施計劃或不知道這些計劃的受訪者比例非常低。調(diào)查表明，CSP在這方面可能比我們預(yù)期的要成熟，或者至少知道需要一個好的敏捷路線圖來幫助自己前進(jìn)。

2.10 物聯(lián)網(wǎng)&垂直行業(yè)技能以及IT和數(shù)據(jù)技能最受關(guān)注

如前所述，CSP認(rèn)為有限的內(nèi)部IT專業(yè)知識是成功實現(xiàn)數(shù)字化轉(zhuǎn)型的最大挑戰(zhàn)之一。在一些領(lǐng)域，CSP需要通過內(nèi)包、重新培訓(xùn)或招聘活動來填補內(nèi)部能力缺口。

有趣的是，調(diào)查中提到的最令人擔(dān)憂的領(lǐng)域是物聯(lián)網(wǎng)和垂直行業(yè)專業(yè)知識。這可能是因為CSP考慮到了即將出現(xiàn)的新5G企業(yè)用例。對于這個問題，我們本以為CSP將主要通過合作來解決，但調(diào)查結(jié)果表明，CSP也認(rèn)為需要從內(nèi)部解決技能短缺問題。

數(shù)據(jù)工程師、程序員/開發(fā)人員、云架構(gòu)師、安全專家和敏捷/DevOps專家也是優(yōu)先考慮對象。

在電信行業(yè)，數(shù)據(jù)工程師短缺并不是一個新問題，但現(xiàn)在CSP還必須應(yīng)對轉(zhuǎn)向基于云的業(yè)務(wù)所帶來的挑戰(zhàn)。這需要相關(guān)技能來擁抱容器化和微服務(wù)架構(gòu)以及敏捷DevOps和CI/CD方法。全球向云的遷移導(dǎo)致需要一個龐大的人才庫來提供支持，其中包括云和安全架構(gòu)師、大數(shù)據(jù)工程師以及敏捷和DevOps專家。但要通過人才獲得優(yōu)勢，CSP必須確保它們使用與其它行業(yè)相同的通用平臺和工具。

2.11 超大規(guī)模公司繼續(xù)擴大它們的影響力

對于供應(yīng)商、大型咨詢公司和集成商來說，CSP將云服務(wù)提供商視為幫助它們執(zhí)行數(shù)字化轉(zhuǎn)型的最重要合作伙伴是一件遺憾的事情。

AWS、Azure和谷歌一直在電信領(lǐng)域擴大影響力，但最近值得注意的是，它們努力與CSP以及網(wǎng)絡(luò)和IT供應(yīng)商(如Amdocs和Netcracker)建立更緊密的戰(zhàn)略伙伴關(guān)系。這在一定程度上受到了最近邊緣云熱潮的影響。在過去一年左右的時間里，AWS在這方面尤其積極。

最新的Omdia研究表明，技術(shù)創(chuàng)新是CSP在選擇OSS/BSS合作伙伴時的首要標(biāo)準(zhǔn)，而且現(xiàn)在這一點比產(chǎn)品可靠性或性價比等其它因素更重要。如果這種趨勢也蔓延到其它領(lǐng)域，那么它顯然將影響數(shù)字化轉(zhuǎn)型合作伙伴的選擇。

伴隨CSP擁抱云和云原生模式、瞄準(zhǔn)廣泛的垂直領(lǐng)域，選擇具有廣泛技術(shù)專長并且能夠提供指導(dǎo)、教育和培訓(xùn)的合作伙伴尤其重要。

2.12 “漸進(jìn)式”和“爆炸式”方法都很受歡迎，但“敏捷”越來越受關(guān)注

漸進(jìn)式的數(shù)字化轉(zhuǎn)型仍然比大型全棧轉(zhuǎn)型得分略高。但相比我們之前的調(diào)查結(jié)果，這一結(jié)果已經(jīng)有了很大的變化——在以前，更多的CSP傾向于漸進(jìn)式方法。

乍一看，這種轉(zhuǎn)變可能令人費解，但有一個更復(fù)雜的現(xiàn)實支撐著它。這并不是說CSP突然重新燃起了對爆炸式改革的興趣。相反，它反映的是一種將兩者結(jié)合起來的轉(zhuǎn)變。

正如一名受訪者所說，它們所青睞的戰(zhàn)略并不是一次大規(guī)模的“爆炸式”變革，而是一系列小規(guī)模的“爆炸式”轉(zhuǎn)型，中間需要保留一定的間隔來實現(xiàn)穩(wěn)定性。這種間隔可以是時間上的，也可以是地域上的，例如一些全球一線CSP正在利用先進(jìn)采用者和數(shù)字加速器戰(zhàn)略。這導(dǎo)致一些受訪者對我們的調(diào)查方法提出疑問，因為如果一家CSP在某個領(lǐng)域十分成熟，而在另一個領(lǐng)域較為落后，那么就很難提供答案。

敏捷方法越來越多地支持跨公司的大規(guī)模轉(zhuǎn)型，同時這也是一種快速、無處不在且自下而上的轉(zhuǎn)型方式，并不是整體僵化、自上而下的轉(zhuǎn)型。我們也許可以稱之為快速、并行的漸進(jìn)式轉(zhuǎn)型。這類方法應(yīng)該屬于“漸進(jìn)式”還是“爆炸式”方法還有待商榷，因為它糅合了兩種方法的元素。

3 對CSP和供應(yīng)商的建議

1)給CSP的建議

數(shù)字化轉(zhuǎn)型不能簡單地通過投資最新技術(shù)或?qū)⒇?zé)任外包給戰(zhàn)略合作伙伴來實現(xiàn)。落實所有對的工具、方法和技能以及賦予員工能力所需的組織和治理結(jié)構(gòu)十分重要。

有限的內(nèi)部IT專業(yè)知識是成功實現(xiàn)數(shù)字化轉(zhuǎn)型的最大挑戰(zhàn)之一。在一些領(lǐng)域，CSP需要通過內(nèi)包、重新培訓(xùn)或招聘活動來填補內(nèi)部能力缺口。招聘對象包括物聯(lián)網(wǎng)和垂直行業(yè)專家、數(shù)據(jù)工程師、程序員/開發(fā)人員、云架構(gòu)師、安全專家、敏捷/DevOps專家等等。

對于數(shù)字化轉(zhuǎn)型，沒有必要在“漸進(jìn)”方式和“爆炸”方式之間做出選擇。相反，可以實施一系列小規(guī)模的“爆炸式”轉(zhuǎn)型，中間需要保留一定的間隔來實現(xiàn)穩(wěn)定性，或者針對不同的地域或領(lǐng)域劃分優(yōu)先級。一些全球一線CSP已經(jīng)采用了這種方法，它們主要使用先進(jìn)采用者和數(shù)字加速器戰(zhàn)略。

2)給供應(yīng)商的建議

對創(chuàng)新的投資和采用云原生的架構(gòu)和方法(包括微服務(wù)、容器化、DevOps、CI/CD)是關(guān)鍵。

供應(yīng)商不僅需要提供最新的技術(shù)，還需要提供兌現(xiàn)承諾所需的工具和方法。與此密切相關(guān)的是，需要面向上述專業(yè)知識領(lǐng)域?qū)SP進(jìn)行指導(dǎo)、教育和培訓(xùn)。如果不這么做(無論是通過自己的專家，還是通過與云計算公司合作)，它們將落后于很多愿意并且有能力這么做的競爭對手。