引言

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

1 報(bào)告摘要

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

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

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

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

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

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

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

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

如圖1所示，各個(gè)地區(qū)存在一些差異——北美CSP的數(shù)字化轉(zhuǎn)型要領(lǐng)先一步。移動(dòng)運(yùn)營(yíng)商通常也走在前面。但不同的工作職能或部門(mén)之間并沒(méi)有明顯的區(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ù)字化項(xiàng)目的速度趨于穩(wěn)定(而不是迅速加速)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

節(jié)約資本支出排在很后面，這并不是因?yàn)镃SP不需要追求資本支出效率，而是因?yàn)橹挥胁扇」?shì)并創(chuàng)造新的收入來(lái)源，它們才能生存下來(lái)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

與其它行業(yè)一樣，電信行業(yè)也越來(lái)越多地采用敏捷方法。第一代敏捷方法主要專(zhuān)屬于小型團(tuán)隊(duì)，但為了管理大型項(xiàng)目和多個(gè)團(tuán)隊(duì)，有必要采用敏捷擴(kuò)展模型。在這個(gè)問(wèn)題中，我們?cè)儐?wèn)CSP正在實(shí)施或計(jì)劃實(shí)施哪些敏捷擴(kuò)展框架。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷方法越來(lái)越多地支持跨公司的大規(guī)模轉(zhuǎn)型，同時(shí)這也是一種快速、無(wú)處不在且自下而上的轉(zhuǎn)型方式，并不是整體僵化、自上而下的轉(zhuǎn)型。我們也許可以稱(chēng)之為快速、并行的漸進(jìn)式轉(zhuǎn)型。這類(lèi)方法應(yīng)該屬于“漸進(jìn)式”還是“爆炸式”方法還有待商榷，因?yàn)樗酆狭藘煞N方法的元素。

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

1)給CSP的建議

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

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

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

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

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

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