大佬都在說數字化轉型，但你真正理解什麼是數字化嗎？

充分理解數字化，明確數字化是什麼以及不是什麼，明確數字化轉型成功的標準是什麼，對於一個技術領導者來說非常重要。

我剛剛採訪完一位架構師。採訪中我問了一個自己最喜歡的問題：「數字化轉型到底有什麼意義？」類似的問題我們也經常聽到，人們本應該對「數字化」這個概念理解得更充分，但實際上並非如此。

廣告：企業的招牌|商務部頒發AAA級信用企業認證

作者｜Reda Hmeid 譯者｜大愚若智

在大量不同情景下把這個問題問過多遍後，我可以很確信地說，大家對這個概念還沒有達成統一共識。實際上很多時候大家被問及這個問題後，更多的表現是困惑或盲目的恐慌。

對於拋出這樣一個棘手的問題，我感覺有些愧疚。同時我也覺得，如果沒有經過徹底的深思熟慮，自己被問到這個問題後一樣會感受到相同的恐慌。有時候，無法清晰表達出數字化轉型的真實含義，並不一定說明對方真的沒想過這個問題。

充分理解數字化，明確數字化是什麼以及不是什麼，對於一個架構師來說非常重要。畢竟我們需要向董事長、CEO、CTO、分析師、開發者，以及其他所有相關人員解釋這些概念。同樣重要的是明確數字化轉型成功的標準是什麼。而充分理解數字化轉型的具體定義，理解數字化這個概念本身，至少可以確定出正確的方向。

那麼如何才能正確「數字化轉型」？組織如何能實現數字化轉型並從中獲益？本次採訪對這些問題提供了很棒的答案。

先來看看字典上對於「數字化」是這麼說的吧。

形容詞：數字化

• 以一系列數字0和1的形式呈現（的信號或數據），通常由電壓或磁性極化強度等物理量的值所代表。

• 以數字信號的方式關聯、使用，或存儲數據或信息。

• 需要或涉及計算機技術的使用。

最後一條解釋很有趣對吧！或大或小不同規模的組織使用「計算機技術」已有數十年的歷史，如果這就是「數字化」的含義，那麼現在的組織為何還要花費大量時間和精力進行數字化轉型？很多東西字典是無法給出足夠解釋的。

我在2016年對「數字化」的定義

「數字化轉型」實際上就是對業務過程進行的重塑，通過重塑使其默認就更加適應更全面的在線環境，從最終用戶的接觸到後端的辦公室工作，全面實現無需人工介入的過程自動化。

為何要數字化轉型

任何組織都應該首先問問自己這個問題。通往數字化的道路並不是免費的……需要大量投入，因此出錢的人必須能全面理解數字化所能帶來的收益。投資回報這種東西非常難以計算，並且只能針對每家公司的具體情況分別進行衡量。原因可以列出很多條，然而最終還是要由你自己來歸納，並匯總成一點：如果不進行數字化轉型，業務就完蛋了。如果不能認真對待數字化，就會被競爭對手超越……然後業務一樣會完蛋。Blockbusters的故事你總聽說過吧！（譯註：Blockbusters是一家線下的VHS錄象帶和DVD影碟租賃連鎖店，2004年全盛時期有6萬員工和8千家店，客戶橫跨全北美。Netflix曾主動提出被併購但被拒。Blockbusters已於2010年破產，Netflix如日中天。）

數字化到底是什麼

• 客戶為先的文化。你的客戶是誰？他們是你數字化服務的用戶。那麼為什麼把他們稱作「客戶」而非「用戶」？長久以來我們都堅持「客戶始終是對的」這樣的心態，如果將自己的用戶視作客戶，無論對方是否為服務付費，那麼我們就會盡一切努力吸引他們，維繫他們，取悅他們。為了數字化轉型，必須打造可以滿足客戶需求的企業文化，可以另客戶獲益的功能，可以快速改變客戶或幫助客戶降低成本的服務。無論做什麼，必須將客戶放在首位。

• 即時反饋?。在數字化世界中，客戶都期待著自己的請求能夠立刻獲得反饋。客戶不會再等待幾分鐘、幾小時甚至數天，僅僅為了知道自己的請求是成功或失敗。數字化世界的響應時間已經開始用毫秒作為單位來衡量。

• 實時?。數字化系統應該能全天候接受請求，應該能按需可用，應該能使用／返回最新數據。最終一致性是一種行之有效的架構方法，但應該按照網路和自動化處理延遲，而非業務過程延遲進行衡量。

• 自動化?。聽起來很明顯，數字化服務應該包含儘可能多的計算機處理過程（最理想狀況是100%由計算機處理），需要的人工介入越少越好。

• 智能?。繁瑣的工作都應交給數字化服務處理，將客戶或其他方面人員需要付諸的精力和所需的理解減至最低。這裡說的「智能」是指服務應當能夠幫助客戶處理最原始的信息並進行相關運算、匯總、提煉和轉換，這一切都無需用戶操心。同時這種智能也意味著服務應當能預測客戶的下一步操作，並提前做好準備，提供建議。

• 在線?。數字化系統應該能通過互聯網從任何地點訪問，不應對設備和使用情況進行任何限制。

• 美觀?。美觀的界面和構造優美的API，數字化時代的任何服務都應具備這樣的特徵。某種程度來說，美觀與否是觀察者的主觀結論，但也意味著易用、直觀，以及能滿足客戶的需求。這意味著可以將對客戶而言最重要的內容直接交付到客戶面前。

• 推進改變?。應該是由數字化服務定義業務過程，而非業務過程定義數字化服務。數字化意味著業務過程需要作出改變，以便適應計算的世界，而非反其道行之。絕不能用在線的方式繼續沿襲以往離線時代的做法。

• 定期改進。?你覺得AWS新功能發布的頻率如何？我簡單統計了一下2016年11月21日到2016年12月5日之間的改動，兩周時間，28次發布！這就是AWS，可能是全球最大規模的數字化平台。大部分客戶對技術並不十分精通，他們並不清楚進行這樣的軟體改進做起來到底有多難……其實他們也不需要關心這些。他們只是希望能看到改進。數字化平台應該儘可能以必須的頻率完善自己。

數字化不是什麼

• 批處理?。在數字化時代，我們不應該繼續依賴離線的數據饋送和調度處理。機器之間的通信應該通過API進行，應通過推送方式在信息可用的那一刻立即進行。這樣可以確保信息始終保持最新狀態。

• 手工處理。，數字化過程的默認形態不應包含任何人工介入或處理。任何離線的介入都應視作一種例外，例如無法使用數字化服務，或面對某些任務，機器學習／處理技術還不夠成熟。例如欺詐檢測，目前依然離不開人工的介入。

• 技術刷新?。技術並不能讓你數字化轉型。步入雲端不能幫你數字化轉型。使用微服務架構不意味著你已經數字化轉型了。使用NoSQL也不意味著數字化。如果你看到某家組織通過強調自己的技術成果表達對數字化轉型進程的支持，那麼也許可以假設他們的數字化之路選錯方向了。

助力轉型

• 雲。—上一節內容已經明確提出：技術本身並不是數字化的目標，本節將開始（並持續不斷地）介紹為什麼技術的恰當選擇可以幫你順利實現數字化轉型。眾所周知，雲計算可以幫助用戶獲得數字化服務所需的縮放性，以及性能和規模。雲計算的背後是一套複雜的分散式系統，但可以良好配合幫你確定最正確的方向。

• 持續集成／持續交付?。從我在1999年開始程序員的職業生涯以來，CI/CD也許是軟體開發領域最大的收穫之一。當時團隊和團隊成員需要分別編寫代碼，很少進行合併，最終上線前需要多天忙碌的工作，通過繁瑣的操作將大家的代碼合併到一起。然後他們悲劇地發現代碼無法集成並配合工作。（實際上我作為開發者參與的第一個項目甚至沒有使用VCS，但這又是另一個故事了）。CI/CD，配合定期進行（通常至少每天一次）的提交和小型（如果需要的話）合併，有助於快速安全地開發出高質量代碼。團隊將能有更多時間專註於開發客戶真正需要的數字化功能。

• 敏捷?。作為一種方法論，也許並不完美。但該方法的基本原則與數字化觀念相當匹配，可以促進以客戶需求為基礎的定期交付。不以敏捷為核心的數字化程序必須付諸更多努力才能滿足轉型的需求。如果敏捷方法論不可行，至少一切行事需要首先考慮到敏捷的基本原則。以人員而非資源為中心，即時（Just in time）設計，不斷演化的架構。無論選擇哪種方法論，這些基本原則都是適用的。

• 用戶研究?。雖然最近才開始研究這一點，但對這方面有很多第一手體驗，同時與很多非常天才和嫻熟的專家有過合作，他們向我證明了只要做得對，用戶研究將成為數字化服務的核心，甚至遠比代碼、架構、方法論更重要。用戶研究可以引導你實現數字化涅槃。為什麼？因為如果「用戶」覺得更易用，你的服務就會更可用，被更多人所使用……最終你也會更加成功。這裡用了「用戶研究」而非「客戶研究」這個詞，因為業界就是這樣稱呼的。

• 簡化設計?。作為架構師，我經常會擁護一件事：我們的設計要儘可能簡潔。若非必要，不要讓設計變得更複雜。不要試圖去解決那種絕對不會自行顯露出來的問題。網上有很多文章解釋了原因，但從數字化的角度來說，簡單的設計可以讓每個人更加關注手頭的事情，進而改善客戶體驗。複雜的設計意味著需要更多維護，可能出錯的東西變得更多，用於確保服務正常運轉所花費的時間遠多於改善數字化體驗所用的時間。

是時候數字化轉型了

組織邁向數字化世界的旅途充滿了挑戰和艱辛，甚至可能存在不小的爭議。在這段旅途中，肯定需要面對針對各種收益所提出的質疑，實際上你可能一開始也有不少疑問。心態從非數字化到數字化的轉變可能是其中最難的部分。任何能夠屹立不倒的組織都有多年來一起同舟共濟的核心員工，這些員工很了解業務，對企業很忠誠，正是這些員工樹立了組織的文化和觀念。然而這些員工面對變動也是最不容易動搖的，需要說服他們相信客戶不是組織內部的「業務」，而是組織所提供服務的用戶。他們需要習慣於每周定期發布，甚至每日發布。他們需要理解，以往的業務過程是針對巨型機的世界，而非針對互聯網或智能手機創建的。那個世界中的所有查詢都是通過代理程序（Agent），而非設備進行的。這樣做並非因為他們缺乏智能和能力，而是因為已經獲得成功，現在希望實現數字化的組織，恰恰都是曾經以某種特定方式成功過的組織，因此他們可能會問：為何還要改變？

此外還會遇到技術挑戰。運行諸如雲端微服務RestFul架構這樣的分散式系統當然能獲得不菲的收益，但還會在延遲、數據一致性、無狀態，以及下游服務失敗等方面遇到挑戰。你的組織中肯定還在使用一些必不可少的遺留系統，這些系統從開發時就沒有考慮過大容量低延遲事務。你的數字化戰略中考慮過如何替換這類系統嗎？如果考慮過，又打算如何進行切換或將數據從老系統遷移到新系統中（想想Strangler模式吧）。但這個過程代價不菲，因此如果不打算替換，遺留的平台又如何融入你的數字化願景？也許數字化平台已經全面做到了實時低延遲運轉，但你依然在使用古老的記錄系統。

在考慮對數字化轉型進行投資時，CEO、CIO，或其他CXO需要抓住機會將組織所獲得的成功下沉到員工身上。讓產品負責人的所有工作都以客戶為中心，並要跳出定勢進行創造性思維。理解這些信條重要性的技術和軟體架構師，同時也要更深入地意識到這些信條會受到業務和客戶目標，而非其他因素的驅使。開發者不能將高質量代碼視作一種負擔，而是應該視作創作和創新方面的自由。測試驅動的開發（TDD）可以提供最無拘無束的Bug修復和支持。同時業務分析師需要能夠將需求解釋為數字化過程，而不是反其道而行解釋為離線的過程。

數字化轉型，這本就不易，但只要具備恰當的人員和耐心，所有在時間和精力方面的投入都會獲得回報。

作者介紹Reda Hmeid是一位自由職業技術架構師兼數字化顧問，自從1999年為初出茅廬的http://ba.com平台編寫代碼後就一直在從事數字化方面的工作。從令人望而生畏的Java 1.4開始編程的Reda非常喜愛Java編程語言，但最近已將關注點轉向Scala和NodeJS以及其他技術。目前Reda在HMRC Digital擔任解決方案主管的職位，這是英國最大的數字化程序開發公司之一。Reda曾任職於英國航空和IBM，德意志銀行也曾是他的客戶。
推薦閱讀：