有幸在IT行業混了20年，有幸在2年前就關注了企業數字化轉型這個話題。但當我看到行業內對數字化轉型所采取的對策時，內心有一種深深的擔憂。

參與數字化轉型的決策部門或者決策者們或許正在不知不覺中犯了左傾的錯誤。以為現在正在砸碎傳統IT這個舊世界，在重建一個新的IT世界。而在決策和執行過程中，“專家學者靠邊站，革命小將放衛星”的現象已經屢見不鮮。

而那些推波助瀾者，???

要么對所謂的雙速或者叫雙模的真實用意一知半解

要么沒有能力看到IT的生態圈和全生命周期，一葉障目。

要么只是想趁亂搶塊紅燒肉吃

實際上，數字化轉型的需求和IT技術的發展相輔相成互相促進。IT技術的發展是在外因推動下的內生性發展，是在傳統IT堅實基礎上，追求更高效、更精益化的變革。就如，愛因斯坦離不開牛頓，牛頓離不開歐幾里德一樣，巨人是因為他站在了巨人的肩膀上。絕對不是推倒重來。

從IT建設的大處講，

敏捷的軟件開發依舊以CMMI為成熟度度量模型

敏捷的運維管理依舊以ITIL為IT服務框架

信息系統規劃依舊以TOGAF為指導…

而DevOps的方法和工具的目的是要把他們拉得更近，而不是拋棄它們。

從IT建設的小處講，一個系統的實現，最終還是要落實到事務、進程、線程等的信息傳遞與反饋。

IT技術就像一潭平靜的水，而水中的生態在默默地進化。而互聯化就像向水里扔一塊磚，甚囂塵上，激起一陣波瀾；但當塵埃落定，最終會沉入水底，融入到IT的生態圈中。

?

對于傳統IT部門來說，一個最大的挑戰是，對新型的業務需求的準備不足，這種業務需求的特點往往是這樣的：客戶數量巨大,業務復雜，需求和變更迭代提出而非一步到位，交付要快，客戶端多屏化，全天候全球化地提供服務，而系統成本要低。

而傳統IT部門在應對大量的企業級和部門級需求的時候，往往采取購買軟件進行實施或者外包團隊開發的方式，逐年制造出大量關系并不緊密的豎井式的單體應用或者巨石應用。這種“借腹生子”的方式使得“平均一個IT人員承擔2至3個系統的開發運維”成為可能，同時IT部門無法也無需建立統一的開發支持體系，系統架構的非平臺化也成必然。

由于業務從“唯穩不破”上升到“唯快不破”的格局，傳統IT應該從這幾個方面去破局：

1，建立開發支持體系（穩定的開發運行團隊和可靠的支持系統及敏捷的流程），全方位支持需求分析架構設計CICD，使得復雜應用的敏捷開發快速交付成為可能（成百上千個服務模塊假如不進行有效管理，后果會是很嚇人的），能自動化的盡量自動化，有規范的盡量按規范進行標準化，抓住客戶核心訴求（需求定位，過濾需求,抓核心KPI），

2，建立新型業務架構，前端技術支持多屏移動，全面解耦業務需求，模塊化微服務化，后端平臺云化，云平臺PaaS化和CaaS化，

3，對已有企業應用，從數據層進行整合，提供統一的數據和業務服務接口以備新型業務的需要。

看起來任務好重，好在業內在開發支持平臺和實踐方法論，前端技術，新業務架構（如用戶行為分析，大數據處理，消息處理，微服務架構等），外圍系統（支付、物流、交互等），主數據服務，內部系統服務接口改造，等等領域已經有了相當積累和成熟的解決方案。只要領導層把握時機，掌控大局，投下資本，各部門敏捷合作，加快戰略部署，提高采購、招人的速度，一兩年內，傳統IT轉型成“又穩又快”的雙模IT是樂觀可期的。

又穩又快地交付IT產品，就如快速交付有質量保證的轎車一樣，不進行精益生產是不行的。沖壓、焊接、油漆、總裝，（開發、測試、部署、運維）；設備和人員的先進性、流程的標準化和執行的自動化是速度和質量的保證。

加大從左到右的工作流的流量，將需求分級過濾，迭代實現，通過自動化的構建、集成和部署，建立一致的開發、測試、預發和生產環境，實現自動化的測試（需求、代碼、功能、安全、非功能），及早發現和隔離缺陷，不讓缺陷和不必要的需求注入生產線。（讓每個車間流出的半成品都是基本符合質量要求的）

加大從右向左的反饋流的流量，突破各個車間各個工序之間的壁壘，建立共同目標和共同解決機制，加強對已交付產品的業務和運行監控，及時向左側反饋。（當交付產品有質量缺陷或者安全問題的時候，統一行動，迅速解決）

創造勇于創新和高信任度的團隊文化，不斷嘗試，重復訓練。使得正向流和反向流運行順暢

由此可見，又快又穩地交付產品，實現精益生產，當務之急，就必須像汽車生產線建設一樣，加大軟件制造流水線整體建設和各個點的自身建設，提高技術水平和自動化程度；同時緊緊抓住用戶和客戶的核心需求，以提高系統的用戶滿意度。有效開展IT內部項目建設，提高業務功能的上線速度和上線率、變更的成功率，減少因不恰當需求和無序的變更而導致的計劃外工作和救火行動。

總結

以上是生活随笔為你收集整理的对企业数字化转型的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。