文章分析了企業(yè)轉(zhuǎn)型失敗的原因，提出了轉(zhuǎn)型悖論，并建議企業(yè)應(yīng)追求持續(xù)和持久的變革，通過小規(guī)模、持續(xù)性的改進來適應(yīng)變化，避免大規(guī)模轉(zhuǎn)型帶來的風(fēng)險。

譯自：The Cautionary Tale of the Browser Wars and Why Business Transformations Often Fail^[1]

作者：Steve Fenton

我們經(jīng)?？吹礁鞔蠊景l(fā)布大規(guī)模轉(zhuǎn)型公告。我們經(jīng)歷了敏捷、數(shù)字化、全渠道和云原生轉(zhuǎn)型浪潮，而人工智能優(yōu)先的轉(zhuǎn)型則如海市蜃樓般在遠方若隱若現(xiàn)。

新聞稿總是樂觀的，但結(jié)果卻令人沮喪地可以預(yù)見。每年有數(shù)萬億美元^[2]浪費在失敗的轉(zhuǎn)型上，而且組織機構(gòu)并不總能從嘗試中幸存下來。雖然大多數(shù)轉(zhuǎn)型徹底失敗，但即使是成功的轉(zhuǎn)型也會讓組織機構(gòu)變得比以前更虛弱。

從瀏覽器大戰(zhàn)中學(xué)習(xí)

如果你能時光倒流25年，你會發(fā)現(xiàn)一場網(wǎng)絡(luò)瀏覽器制造商之間的大戰(zhàn)正在上演。Mosaic早已消失，Netscape Navigator以70%的市場份額（1998年）占據(jù)主導(dǎo)地位，但他們即將把這一切輸給Internet Explorer，后者很快扭轉(zhuǎn)局面，獲得了75%的市場份額（1999年）。當時的Firefox、Chrome、Edge和Vivaldi甚至還不存在，所以Internet Explorer已經(jīng)算是最好的了。

毫無疑問，Internet Explorer比Netscape Navigator更好，但微軟是如何超越這個占據(jù)主導(dǎo)地位的瀏覽器的呢？ Joel Spolsky 將市場份額的損失^[3]歸因于Netscape決定從頭開始重寫其瀏覽器。當他們花了3年時間從頭開始構(gòu)建瀏覽器時，其他所有人都在向前飛奔。

正如Spolsky所說，“他們認為舊代碼是一團糟的原因，是因為編程的一條基本法則。閱讀代碼比編寫代碼更難。開發(fā)人員^[4]為創(chuàng)建基于“更簡潔代碼”的新瀏覽器而采取的每一項行動都代表著對來之不易的知識的喪失。代碼看起來很混亂，因為它處理了開發(fā)人員最初沒有意識到并且現(xiàn)在已經(jīng)忘記的場景和極端情況。

當你刪除所有這些混亂時，你不是在讓事情變得更整潔和更好；你只是在破壞事情。

切斯特頓的柵欄

對于這種在你知道事物存在的原因之前就將其拆除的問題，有一個原則。它被稱為“切斯特頓的柵欄”，這個名字來源于 G. K. 切斯特頓在1929年描述這個想法的方式：

“在這種情況下，存在某種制度或法律；為了簡單起見，我們假設(shè)有一道柵欄或大門橫跨道路。比較現(xiàn)代的改革家興高采烈地走到它面前說，“我看不出這有什么用；讓我們把它清理掉。”對此，比較聰明的改革家最好回答：“如果你看不出它的用處，我當然不會讓你把它清理掉。走開，去思考。然后，當你回來告訴我你確實看到了它的用處時，我可能會允許你摧毀它。”

要應(yīng)用此規(guī)則，你必須在移除某些東西之前弄清楚它存在的原因。在確定這一點的過程中，你通常會發(fā)現(xiàn)其存在的必要性。你可以將切斯特頓的柵欄應(yīng)用于所有事物，從你想從廚房里移除的不方便的柱子（它支撐著上層樓的墻壁的重量）到從頭開始重寫Netscape。

這里有一個至關(guān)重要的教訓(xùn)，因為它也適用于組織機構(gòu)的轉(zhuǎn)型。

轉(zhuǎn)型失敗的原因

組織機構(gòu)進行轉(zhuǎn)型是因為它們發(fā)現(xiàn)了一個根本性的薄弱環(huán)節(jié)，以至于它們希望顛覆整個組織機構(gòu)來完成糾正它的任務(wù)。如果你無法頻繁地交付軟件，你需要一個“敏捷轉(zhuǎn)型”。如果你在實體店運營你的業(yè)務(wù)^[5]，而客戶無法在線與你互動，你需要一個“數(shù)字化轉(zhuǎn)型”。

組織機構(gòu)抵制轉(zhuǎn)型帶來的^[6]那種變革。它們的控制結(jié)構(gòu)旨在維持現(xiàn)狀。每一次轉(zhuǎn)型嘗試都面臨著無數(shù)的小戰(zhàn)役：質(zhì)疑該倡議的預(yù)算審查、保護自己領(lǐng)地的中層管理人員、偏愛舊方式^[7]的流程。在這些日常沖突中，每一次輕微的損失都會削弱轉(zhuǎn)型成功的機會。

但是，對于成功的轉(zhuǎn)型，還有一種更為壯觀的失敗在等待著。你看，當一個轉(zhuǎn)型完全成功時，它贏得了所有的沖突，并拆除了所有目光所及的柵欄。拆除柵欄柱的過程沒有時間爭論其目的，因此轉(zhuǎn)型后的景象需要一個重新學(xué)習(xí)數(shù)千個過去教訓(xùn)的過程。

通常重新學(xué)習(xí)的過程時間有限，因為下一次轉(zhuǎn)型即將來臨。

轉(zhuǎn)型悖論

你不會在健康的公司中發(fā)現(xiàn)大規(guī)模的轉(zhuǎn)型。發(fā)起如此大規(guī)模的變革沖擊波的唯一原因是，該組織機構(gòu)已經(jīng)與它所處的現(xiàn)實脫節(jié)。需要多年的否認才能建立起如此巨大的差距^[8]，以至于你必須使用轉(zhuǎn)型的蠻力來彌合它。

該組織機構(gòu)在年度審查中批評我倡導(dǎo)基于Web的技術(shù)，后來發(fā)起了一個大規(guī)模的數(shù)字化轉(zhuǎn)型項目，試圖彌補失去的十年。他們的總部坐落在一條以他們的組織機構(gòu)命名的道路上，現(xiàn)在空無一人。

這只是眾多例子中的一個，但教訓(xùn)很明確：你越是長期和努力地抵制周圍的變化，越多的厄運就會滲入你的組織機構(gòu)。如果你想發(fā)現(xiàn)這種根深蒂固的組織機構(gòu)腐敗，你只需要看看它們的首要癥狀：轉(zhuǎn)型項目。相反，那些關(guān)注周圍世界變化并不斷進行微小調(diào)整的組織機構(gòu)，永遠不會積累到需要轉(zhuǎn)型的衰敗程度。

把它想象成洗澡。適應(yīng)性組織機構(gòu)始終將一只手放在溫度閥上，隨著水溫的波動進行微小的調(diào)整。相反，僵化的組織機構(gòu)會忽略逐漸的變化，直到它們被凍僵或燙傷，然后它們會瘋狂地將閥門從一個極端旋轉(zhuǎn)到另一個極端，從而造成更大的混亂。

你只需要嘗試轉(zhuǎn)型，因為你已經(jīng)拖延到了超出最后負責任的時刻。從各方面來看，失敗已經(jīng)發(fā)生。轉(zhuǎn)型是組織機構(gòu)的最后一搏，因此它們接受它將造成的附帶損害；必須沿途夷平的無數(shù)柵欄，以及由此造成的饑餓的山羊?qū)r(nóng)作物的損失。

這就是轉(zhuǎn)型的悖論。你不應(yīng)該這樣做，但如果你正在這樣做，這可能是你最后的手段，所以你必須繼續(xù)下去。

持久的變革更加慎重

更好的做法是追求持續(xù)和持久的變革。這是一個更慎重的過程，它用進行實驗的勇氣取代了否認。為了使變革能夠持續(xù)下去，你需要以較小的規(guī)模并且始終如一地實施它。

與其將一個組織機構(gòu)從紙質(zhì)轉(zhuǎn)換為數(shù)字化，不如通過使對變革的響應(yīng)成為其運營模式的一部分，從而將一個組織機構(gòu)從靜態(tài)轉(zhuǎn)換為動態(tài)。這需要一些關(guān)鍵的組織機構(gòu)能力，特別是具有心理安全感的生成式文化和變革型領(lǐng)導(dǎo)力。

你不是強迫人們進行實驗，你只是讓這樣做變得安全。

持續(xù)的小規(guī)模變革降低了不得不爭先恐后地追趕的機會。你不會進行像房屋清理式的轉(zhuǎn)型，扔掉一切，然后發(fā)現(xiàn)自己重新購買了本應(yīng)保留的昂貴物品，而是會防止囤積，從而避免必須將所有東西都扔進垃圾箱。

具有諷刺意味的是，那些已經(jīng)學(xué)會如何擅長持續(xù)小規(guī)模變革的組織機構(gòu)，也更有能力在需要時進行更戲劇性的變革。他們不會進行轉(zhuǎn)型，而是進行 Kaikaku 或 Kaizen Blitz，以切換更大的拼圖塊來增強他們的優(yōu)勢。與轉(zhuǎn)型不同，這些激進變革的方法首先要了解當前狀態(tài)和目標狀態(tài)，這通常會減少達到預(yù)期目標所需的^[9]總變革量。

如果你想讓變革成功，你需要讓它一直發(fā)生。

引用鏈接

[1] The Cautionary Tale of the Browser Wars and Why Business Transformations Often Fail:https://thenewstack.io/the-cautionary-tale-of-the-browser-wars-and-why-business-transformations-often-fail/

[2]數(shù)萬億美元:https://hbr.org/2019/03/digital-transformation-is-not-about-technology

[3]市場份額的損失:https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[4]代碼比編寫代碼更難。開發(fā)人員:https://thenewstack.io/idps-give-developers-more-freedom-to-write-code/

[5]運營你的業(yè)務(wù):https://thenewstack.io/what-workloads-do-businesses-run-on-kubernetes/

[6]轉(zhuǎn)型帶來的:https://thenewstack.io/four-transformational-changes-coming-to-ai-in-2025/

[7]偏愛舊方式:https://thenewstack.io/five-ways-process-automation-can-streamline-itops/

[8]建立起如此巨大的差距:https://thenewstack.io/building-with-mcp-mind-the-security-gaps/

[9]減少達到預(yù)期目標所需的:https://thenewstack.io/how-real-time-database-design-boosts-total-cost-of-ownership/