在過去的十年里，CIO大力投資于數(shù)字化轉(zhuǎn)型計(jì)劃，旨在改善客戶體驗(yàn)、構(gòu)建數(shù)據(jù)分析能力，并通過自動(dòng)化實(shí)現(xiàn)生產(chǎn)力提升，這些計(jì)劃的基礎(chǔ)是一系列旨在加快交付周期的技術(shù)能力和策略，如建立產(chǎn)品管理紀(jì)律、構(gòu)建云架構(gòu)、發(fā)展DevOps能力和培育敏捷文化。

不幸的是，許多數(shù)字化轉(zhuǎn)型的商業(yè)影響仍然未能達(dá)到預(yù)期。

例如，KPMG報(bào)告稱，51%的技術(shù)高管表示他們并未從數(shù)字化轉(zhuǎn)型投資中看到性能或盈利的提升。哈佛商業(yè)評(píng)論的《數(shù)字化轉(zhuǎn)型的價(jià)值》報(bào)告指出，“雖然全球有89%的大型公司正在進(jìn)行數(shù)字化和人工智能轉(zhuǎn)型，但他們僅實(shí)現(xiàn)了預(yù)期收入提升的31%和預(yù)期成本節(jié)約的25%。”

詢問CIO們關(guān)于他們面臨的最大數(shù)字化轉(zhuǎn)型挑戰(zhàn)時(shí)，他們可能會(huì)提到人員問題，或者專家認(rèn)定的變革管理實(shí)踐中的缺口。當(dāng)CIO無法推動(dòng)變革時(shí)，新的數(shù)字產(chǎn)品和技術(shù)能力可能會(huì)變成擱置的產(chǎn)品，商業(yè)價(jià)值也會(huì)因此延遲或減少。

Dunelm Associates的CIO兼管理合伙人Martin Davis表示，不要過早宣布成功：“許多項(xiàng)目在流程或系統(tǒng)實(shí)施時(shí)過早宣布成功，卻未意識(shí)到變革管理工作必須在實(shí)施后繼續(xù)一段時(shí)間，以實(shí)現(xiàn)其全部價(jià)值。”

協(xié)調(diào)變革

數(shù)字化轉(zhuǎn)型計(jì)劃中的變革管理包括吸引利益相關(guān)者參與規(guī)劃，幫助員工易于采用，以及改善客戶和所有參與計(jì)劃的人的體驗(yàn)。

在任何轉(zhuǎn)型計(jì)劃的開始階段，規(guī)劃階段會(huì)出現(xiàn)動(dòng)力下降，這時(shí)需要說服高管投資于數(shù)字化轉(zhuǎn)型，并與業(yè)務(wù)利益相關(guān)者合作，制定優(yōu)先級(jí)路線圖。由于高管和利益相關(guān)者協(xié)調(diào)問題導(dǎo)致的長時(shí)間、復(fù)雜和昂貴的前期規(guī)劃過程可能會(huì)錯(cuò)失機(jī)會(huì)，尤其是當(dāng)競爭對(duì)手更快地將能力推向市場時(shí)。

但更大的挑戰(zhàn)通常出現(xiàn)在下游，當(dāng)負(fù)責(zé)領(lǐng)導(dǎo)數(shù)字化轉(zhuǎn)型計(jì)劃的數(shù)字先鋒們必須與終端用戶一起處理流程變化和技術(shù)采納問題時(shí)。當(dāng)DevOps團(tuán)隊(duì)發(fā)布對(duì)應(yīng)用程序、儀表板和其他技術(shù)能力的更改時(shí)，終端用戶會(huì)在有效利用新能力之前經(jīng)歷生產(chǎn)力下降。這種下降延遲了業(yè)務(wù)開始實(shí)現(xiàn)所交付價(jià)值的時(shí)間。

雖然有許多變革管理框架和認(rèn)證，但許多框架將變革視為與CIO用于規(guī)劃和交付數(shù)字化轉(zhuǎn)型計(jì)劃的產(chǎn)品管理、敏捷和DevOps方法論不同的學(xué)科。這是一個(gè)問題，因?yàn)樾g(shù)語、哲學(xué)和職責(zé)之間的不匹配可能導(dǎo)致流程缺口，或更糟糕，不同領(lǐng)導(dǎo)者推動(dòng)不兼容的方法論之間的流程戰(zhàn)爭。

智能制造公司Connektedminds的首席執(zhí)行官及主要負(fù)責(zé)人Joanne Friedman博士表示，數(shù)字化轉(zhuǎn)型的成功協(xié)調(diào)需要跨學(xué)科的整合交響曲：“CIO面臨的挑戰(zhàn)是調(diào)和不同的學(xué)科，如設(shè)計(jì)思維、產(chǎn)品管理、敏捷方法論和數(shù)據(jù)科學(xué)實(shí)驗(yàn)。這就像試圖讓爵士四重奏、搖滾樂隊(duì)、古典樂團(tuán)和DJ和諧演奏。”

因此，減少生產(chǎn)力下降和簡化終端用戶采用實(shí)踐必須符合數(shù)字化和轉(zhuǎn)型運(yùn)營模型。讓我們考慮三個(gè)領(lǐng)域，CIO和數(shù)字化先鋒們可以將變革管理注入他們的數(shù)字化轉(zhuǎn)型計(jì)劃中，這種方式比將變革管理作為單獨(dú)的附加項(xiàng)更有效。

產(chǎn)品經(jīng)理必須從“為什么”開始

暢銷書作家西蒙·西奈克(Simon Sinek)建議偉大的領(lǐng)導(dǎo)者從“為什么”開始，這是有充分理由的。

Clear Skye的首席執(zhí)行官約翰·米爾本(John Milburn)說：“與同事合作時(shí)，要關(guān)注‘為什么’而不是‘做什么’。雖然CIO看到了大局，但他們的同事需要知道這種變化將如何使他們受益。”

CIO必須采取措施確保他們的同事理解數(shù)字化轉(zhuǎn)型計(jì)劃的重要性，他們也必須依靠他們的數(shù)字化先鋒對(duì)其利益相關(guān)者和團(tuán)隊(duì)做同樣的事情。

我們要求員工實(shí)施許多變化，并持續(xù)改善結(jié)果。除非員工理解一個(gè)計(jì)劃的重要性、它將在哪里產(chǎn)生商業(yè)價(jià)值以及為什么他們應(yīng)該關(guān)心，否則他們會(huì)將此視為額外的工作和壓力。StarCIO的變革顧問和教練Janette Gleyzer表示，數(shù)字化先鋒應(yīng)該通過回答反思性問題來解釋“為什么”，例如什么定義了成功以及過去的失敗中出現(xiàn)了哪些模式。

數(shù)字化轉(zhuǎn)型中變革管理的最頂層由產(chǎn)品經(jīng)理或某些組織中的項(xiàng)目經(jīng)理負(fù)責(zé)。他們必須通過傳達(dá)一個(gè)簡單易懂的愿景聲明來開始這一過程，該聲明定義了目標(biāo)客戶、價(jià)值主張和戰(zhàn)略重要性。

大型組織將超越創(chuàng)意工作流程、愿景聲明的編寫和制定路線圖，進(jìn)行價(jià)值流程繪制以幫助將戰(zhàn)略與執(zhí)行、交付和變革管理聯(lián)系起來。價(jià)值流程繪制可以成為幫助員工了解其工作價(jià)值的重要工具。

ExpandAP的創(chuàng)始人兼首席執(zhí)行官保羅·文克(Paul Wnek)表示：“精明的數(shù)字化轉(zhuǎn)型領(lǐng)導(dǎo)者會(huì)依靠價(jià)值流程繪制來使每個(gè)決策者和利益相關(guān)者熟悉技術(shù)在每一步的工作方式，展示它對(duì)企業(yè)和個(gè)人能做什么的清晰愿景。當(dāng)數(shù)字化先鋒考慮到他們將接觸的所有利益相關(guān)者，并分別解決每個(gè)利益相關(guān)者的關(guān)切時(shí)，成功的機(jī)會(huì)最大。”

敏捷團(tuán)隊(duì)必須在沖刺期間承諾進(jìn)行變革管理

變革管理不僅僅是產(chǎn)品經(jīng)理的責(zé)任。他們應(yīng)該為其敏捷團(tuán)隊(duì)設(shè)定期望，簡化最終用戶的采用過程。

敏捷和Scrum方法論大多強(qiáng)調(diào)交付活動(dòng)，當(dāng)團(tuán)隊(duì)專注于每個(gè)沖刺完成用戶故事時(shí)。產(chǎn)品負(fù)責(zé)人和Scrum主管還必須使團(tuán)隊(duì)參與規(guī)劃活動(dòng)，包括編寫用戶故事、估算工作量和整理待辦事項(xiàng)列表。

Solix Technologies的執(zhí)行董事約翰·奧特曼(John Ottman)說：“除了推動(dòng)Scrum的節(jié)奏、協(xié)調(diào)和儀式之外，Scrum主管需要與產(chǎn)品負(fù)責(zé)人緊密合作，驗(yàn)證史詩、用戶故事和任務(wù)是否都清晰且得到適當(dāng)記錄，以確保每次沖刺的預(yù)期結(jié)果符合期望。”

文檔和精心編寫的用戶故事指導(dǎo)團(tuán)隊(duì)完成工作并滿足要求。當(dāng)產(chǎn)品負(fù)責(zé)人與利益相關(guān)者、主題專家和參與用戶驗(yàn)收測試的員工分享要求時(shí)，它們也可以用于變革管理活動(dòng)。

向最終用戶展示用戶故事中的所有細(xì)節(jié)可能會(huì)讓人不知所措，因此敏捷團(tuán)隊(duì)?wèi)?yīng)該尋求簡化它們以支持變革管理活動(dòng)。例如，Atlassian Confluence等工具可以從Jira Software中提取用戶故事的部分，以便產(chǎn)品負(fù)責(zé)人簡化展示。另一個(gè)選項(xiàng)是使用生成式AI工具來總結(jié)一個(gè)沖刺中完成的用戶故事，并幫助編寫發(fā)布說明。最佳選項(xiàng)是當(dāng)產(chǎn)品團(tuán)隊(duì)在開放的沖刺審查會(huì)議中審查要求，邀請(qǐng)關(guān)鍵利益相關(guān)者和最終用戶參加。

更進(jìn)一步，我希望看到敏捷團(tuán)隊(duì)將變革管理活動(dòng)作為他們每個(gè)沖刺承諾的另一種工作形式。這應(yīng)該包括參與培訓(xùn)活動(dòng)、訪問最終用戶、審查性能指標(biāo)以及捕獲他們可以用來改進(jìn)工作的其他形式的反饋。

DevOps不應(yīng)該破壞變革管理

敏捷團(tuán)隊(duì)多久應(yīng)該將代碼發(fā)布到生產(chǎn)環(huán)境中?

許多采用 DevOps 最佳實(shí)踐的團(tuán)隊(duì)已經(jīng)使用 CI/CD 自動(dòng)化了他們的部署流程，實(shí)現(xiàn)了持續(xù)測試，并對(duì)他們的安全和操作有足夠的信心來實(shí)施持續(xù)部署。

自動(dòng)化提高了質(zhì)量并減少了工作量，但頻繁的部署可能不適合最終用戶，并可能加重變革管理活動(dòng)的負(fù)擔(dān)。DevOps 團(tuán)隊(duì)必須考慮對(duì)最終用戶的影響，并且他們有幾個(gè)選擇來減少對(duì)最終用戶的影響。

以下是四個(gè) DevOps 建議，以增加部署頻率而不復(fù)雜化變革管理并對(duì)最終用戶產(chǎn)生負(fù)面影響。

僅對(duì)影響最終用戶較小且變革管理要求最低的小修補(bǔ)和微小更改自動(dòng)化持續(xù)部署。

當(dāng)部署更改工作流、用戶界面和新功能時(shí)，實(shí)行更加受控的發(fā)布管理流程。

創(chuàng)建功能標(biāo)記并決定哪些用戶可以對(duì)新功能提供早期反饋，然后再向更多人推廣。

利用金絲雀發(fā)布和控制將新功能推出給小部分用戶群體。

奧特曼補(bǔ)充說：“首先向選定的少部分用戶實(shí)施新功能，讓他們進(jìn)行測試并提供反饋，可以確保一旦變更被接受，更新對(duì)整個(gè)用戶群體來說都將是成功的。”

變革管理實(shí)踐是從數(shù)字化轉(zhuǎn)型舉措中取得商業(yè)成果的不可或缺的部分。為了簡化采用過程，CIO 和數(shù)字化先鋒應(yīng)該考慮將變革管理實(shí)踐融入他們的數(shù)字運(yùn)營模式，以便最終用戶在整個(gè)旅程的各個(gè)階段學(xué)習(xí)、體驗(yàn)和采納變革。