天天看點

傳統企業數字化轉型,到底難在哪裡?

數字化浪潮轟轟烈烈,被卷入其中的不隻是 IT 技術行業,各行各業都裹挾其中。

2022 年的政府工作報告提出,要促進數字經濟發展,加強數字中國建設整體布局,建設數字資訊基礎設施,推進 5G 規模化應用,促進産業數字化轉型,發展智慧城市、數字鄉村。

然而,這并不是政策第一次強調 “數字經濟”。事實上,從 2017 年的 “促進數字經濟加快成長” 開始,這已經是 “數字經濟” 第五次被寫入政府工作報告了。

相應地,數字化轉型浪潮也在各行各業中興起,熱度一時無兩。近年來,O2O、大資料等概念先後湧現,也出現了一批新型的數字化科技企業,這給傳統企業帶來了無形的壓力。固守一隅,很難不被時代淘汰;而激進闖入,又難以保證不落入 “起了個大早,趕了個晚集” 的尴尬境地。

傳統企業不像網際網路企業,不僅無法在開發技術團隊上投入很大比例的資源,而且還要求強業務導向、為業務賦能。與此同時,傳統企業在數字化轉型中,又總會遇見這樣那樣的問題,這就呼籲更新的解決辦法和更好用的工具出現。

::: hljs-center

01 “數字化” 實作不易,傳統企業面臨 “内外部困境”

:::

什麼是 “數字化”?有了解過的人都知道,“數字化” 絕不是将流程、表單、資料等搬到電腦上這麼簡單。

目前,較多的傳統企業内部其實已經存在不少業務表單系統,這些系統全部都是 “資訊化” 的,以流程流轉和資訊采集為主。這些資訊系統就像一根根煙囪,彼此之間沒有打通,各自為政。如果管理層想要看到全局的業務情況,幾乎是不可能的,部門牆阻礙調取,而且即使調取了資料口徑也不一樣。

數字化強調什麼?資料線上僅僅是最初級的一方面,數字化最終要達成的是 —— 資料分析驅動業務改善、實作精益營運或者業務增長、數字驅動整個企業商業和業務模式的轉型。

這就不再是涉及某個業務或者部門的 “小打小鬧” 了,而是牽連整個公司戰略的 “重大舉措”。面對這種情況,很多傳統企業往往決策艱難:

數字化轉型具體應該從哪裡入手?在數字化程序中軟體開發有多重要?

是否需要組建一支專業的開發團隊?如果所有系統外包,公司會喪失自主權嗎?

這個團隊要如何打造?成本幾何?

針對公司本身,數字化的目标定在哪裡才是最合适的?

面臨改革轉型,公司内部的阻力會有多大?

公司最後的收益有多大?值得投入這麼大的成本嗎?

……

這些都是非常現實的問題,幾乎每個傳統企業在數字化轉型中都會遇到。總體來看,他們受到的數字化阻礙不是來自企業内部,就是受制于外部技術環境,而外部技術環境的阻力尤為要命。

一、企業内部困境:數字化需要 “戰略定力”

如前所述,數字化動辄就是集團層面的戰略,其項目的體量可想而知,它并非是一朝一夕即可完成的。

首先,一個關鍵人員的流動就可能導緻項目中斷、甚至從頭再來;

其次,部門之間難免存在利益鬥争,直接影響相關負責人在決策時的戰略搖擺,進而讓項目規劃設計變得糟糕;

再次,人越多,溝通越複雜,溝通成本也就越高,溝通成本不僅導緻需求方和研發方,還有測試方和運維方出現很多問題;

最後,是風險問題,這一方面最典型的例子就是 Kmart,當年 Kmart 花費 14 億美元啟動 IT 現代化項目,以期奪回被沃爾瑪和塔吉特搶走的市場佔有率。結果并不理想,傳統企業數字化轉型的本意是降本增效以提升企業核心競争力,但一旦轉型失敗,很可能會惡化企業處境,讓利潤率下降、成本壓力上升。

以上問題十分考驗一個傳統企業在數字化轉型過程中的 “戰略定力”。一旦确定目标,就要走到底,否則會面臨較大的沉沒成本。

二、外部技術環境困境:4 大門檻,十分兇險

1、關鍵人才少,偏偏又人才需求量大

有業内人士曾表示,人才非常難找,在網際網路這個世界裡面要找一個很好的工程師或者架構師,比登天還難。

随着網際網路的興起,現在的開發分得比以前更細。應用機關提出一個需求,然後交給研發,去做了解和開發,然而,研發人員對需求的了解未必十分準确與充分。是以,架構師應運而生。

但是,架構師在這個行業裡面是非常稀缺的。因為很少有公司有環境能夠讓一個人去曆練他的技術。阿裡巴巴有,騰訊有,但除了這種頭部企業,其他企業根本沒有。

架構師這種關鍵人才少是一方面,數字化轉型中各類人才的需求量大又是另一方面。

現在研發工程師分前端和後端。此外,現在的測試工程師也是很專業的,不像以前軟體開發完了開發人員自己測試完,然後再給業務部門測試一下。現在還有黑白盒測試,專注的領域跟以前也不太一樣。

現在的運維跟傳統的也不太一樣,以前傳統的運維把機器裝置維護好就行。現在的網際網路行業裡面底層有機器裝置,再一上層有雲原生,裡面還有其他技術棧,現在又有容器,最上層是在雲上疊加應用,是以整個運維體系也變得不太一樣。

這就是企業做網際網路技術的軟體需要很多人的原因。

2、“黑盒效應” 和經驗積累困境

軟體開發技術目前被掌握在少數人手裡,,是以很多人對軟體開發效率并不了解。

于是,在很多人來看,軟體開發就是個黑盒子,軟體人員說實作某個功能需要 10 天,是無法被反駁的,因為管理人員不懂技術,而專業人士會将能力把持在自己身上,以保持自身價值,很多事情會 “黑箱操作”。

除此之外,傳統企業也難以累積到關鍵的知識經驗。開發的所有系統的經驗值都在研發人員身上,不被企業所有。這就會導緻企業系統将來的運維和疊代變得痛苦。

3、成本之殇:不僅是開發,還涉及後續維護

許多行業在做資料的轉移時,一直在做重複的工程,導緻成本非常高昂,很多中小企業根本無法進行數字化轉型。

還有很多人以為,軟體傳遞給使用者事情就算完成了,其實并非如此。如果軟體後續維護做不到簡單便捷、低成本,很可能會讓之前的一切努力都白費。

4、作業方式落後,亟待新理念落地

之前,一些數字化轉型的先行者受到了 “傳統瀑布式開發” 的限制。瀑布式開發是典型的各自為戰,一個流程到另一個流程,開發與運維之間沒有交流,讓 “灰色地帶” 滋生風險。

一代或二代軟體開發中,基本都是以功能性為主,而且産品和技術線路非常單一,運維也更多的是靠硬體來支撐。

DevOps 理念的誕生讓大家看到了希望。傳統企業在切入數字化賽道時,如果一開始就采用這一思路,可以少走很多彎路。

::: hljs-center

02 技術是良藥,當下 DevOps 工具中軟體機器人脫穎而出

:::

“所有的技術沒有好或不好,隻有适不适用。我們不應該為了技術而技術,我們應該思考這個技術應該服務什麼樣的企業,讓這個企業有更好的發展。” 飛算雲智總裁陳定玮近日在 SoFlu 軟體機器人産品釋出會上表示。

綜上所述, 技術才是解決問題的關鍵,隻要把技術問題解決了,其他問題就能迎刃而解。

然而,現在市面上很多的低代碼平台并沒有讓企業真正受益。因為它們隻在解決很表面的功能性問題,并不能真正提高開發品質,或者降本增效。很多低代碼平台雖然都聲稱能夠提高效率,但究竟能夠提高多少,并沒有一個實際的參數值來參考。

用一個案例來說明 SoFlu 軟體機器人的有效性。中石油聘請近 20 人的外部團隊花了一年左右時間開發了一個大型電商平台,但随着使用者數量的增加和具有企業特色的功能需求不斷提出,原有平台架構在功能、性能和擴充性方面已無法滿足商城的發展需求。是以,需要對商城平台進行重構。

在之後的總結中,中石油資訊化團隊發現重構商城存在的問題包括:

1)平台修複工程量巨大,其中涵蓋商品推薦、下單、客服、秒殺等衆多複雜單元,系統設計的開發量很大;

2) IT 團隊開發水準參差不齊,進度受團隊能力影響嚴重,且手工編碼的标準不統一,導緻代碼品質不佳,項目返工頻繁;

3)項目事件緊迫,該電商平台是集團年度重點項目,上線需求緊迫。

最終,在 5 個 SoFlu 軟體機器人的協助下,中石油的 9 人小團隊隻花了 45 天,就高品質完成了任務。其中,這個電商平台要求的秒殺、拼團、砍價、供應商管理、智能客服、千人千面等功能應有盡有。

SoFlu 軟體機器人能夠做到這種程度,關鍵在于自身的核心優勢:

一、自動化:一個人就能玩轉軟體開發全流程

通過與 SoFlu 軟體機器人協同,一個人就能夠完成軟體開發全流程,因為 SoFlu 軟體機器人的理念是重設計、輕開發、輕測試、輕運維。在 SoFlu 軟體機器人的協助下,企業能夠輕松實作開發需求。

陳定玮做了一個很形象的比喻:

我們是在輔助工程師去高效地完成設計賦予的任務,就像自動駕駛一樣,自動駕駛并不能取代駕駛員,而是去輔助他,讓人開車的體驗變得更好、更安全、更高效。

同理,SoFlu 軟體機器人可以幫助人快速實作軟體開發或者快速了解軟體開發是怎樣一回事。

除此之外,SoFlu 軟體機器人的自動化開發還成功實作了開發流程從 “人治” 到 “法治” 的轉變。對此,SoFlu 軟體機器人整合了 151 個問題點,形成十大流水線。讓 DevOps 真正落地。

自動化開發在一定程度上還解決了人才問題,讓軟體生産變得更高效、更簡約。

二、可視化:縮減溝通成本,提升開發效能

SoFlu 軟體機器人應用可配置和可視化的模式進行系統的開發,用可視化界面替代傳統敲代碼的程式設計模式,拖拽平台元件繪制業務流程圖就可實作系統的自動化開發。業務邏輯的設計直覺展現,後期修改流程或是檢查 BUG 也非常清晰簡便。

所有流程可視化可以讓工程師直覺地了解需求,由此大大縮減開發與業務之間的溝通成本,并提升開發效能。

三、全棧式工具:前端後端一體化

在 SoFlu 軟體機器人的理念中,是将運維功能在開發端埋入,進行鍊路追蹤的。不僅是開發,運維也同樣重要。因為運維關系到營運,以及企業的發展。

一開始,SoFlu 軟體機器人做的是後端開發工具。但這不是終點,SoFlu 軟體機器人還陸續上線了全自動測試平台、全自動運維平台以及全自動前端開發平台,這是一個體系。

為什麼要做前端開發工具呢?是因為前端的表單、流程模組化都是必要的。客戶可以去根據應用場景去選擇到底是隻要用前端技術,還是要用前後端分離的技術,或者是隻要用後端技術。

客戶可以按照自己的需求,去比對不同的工具,做到真正的降本增效。

關于自動化測試。現在市面上很多測試平台因為測試跟研發的脫離,而不能做到精準回歸測試。陳定玮認為,測試要真正做到精準化,就一定要與研發關聯。

SoFlu 軟體機器人的測試平台可以與開發平台一鍵關聯,自動生成測試腳本,并完成測試。開發平台改動任何接口或計算邏輯,測試平台都能檢測到,由此實作精準回歸測試。

除此之外,全自動運維平台提供 170 個接口,友善使用者精準定位問題。

目前,市面上很多原生低代碼廠商,基本上不具備後端開發功能。而 SoFlu 軟體機器人在具備前、後端開發功能的基礎上,還能夠獨立部署,是以可以在能力次元和應用次元兩個方面,保持明顯優勢。

::: hljs-center

傳統企業數字化轉型,到底難在哪裡?

:::

::: hljs-center

能力次元對比

:::

::: hljs-center

傳統企業數字化轉型,到底難在哪裡?

:::

::: hljs-center