在當今數(shù)字化浪潮席卷各個行業(yè)的時代，企業(yè)數(shù)字化建設已成為關乎企業(yè)生存與發(fā)展的關鍵戰(zhàn)略。而對于眾多企業(yè)在推進數(shù)字化項目過程中，產(chǎn)品和供應商選型無疑是至關重要的一環(huán)。

因此今天準備聊下企業(yè)數(shù)字化選型中的三個關鍵點。

1. 產(chǎn)品需要具備足夠開放性

首先，產(chǎn)品開放性是必須要重點關注的方面。

當一款產(chǎn)品融入企業(yè)整體 IT 應用架構后，其價值不僅僅體現(xiàn)在基礎功能的提供上，更關鍵的是要能與其他 IT 系統(tǒng)實現(xiàn)高度集成與協(xié)同。這就要求產(chǎn)品具備足夠的開放性。

那么，這種開放性具體體現(xiàn)在哪兒呢？

一方面，產(chǎn)品自身的底層數(shù)據(jù)庫以及數(shù)據(jù)庫表需要足夠開放。因為在很多時候，企業(yè)為了滿足個性化需求，進行二次擴展定制開發(fā)一些查詢功能時，往往需要直接從數(shù)據(jù)庫表中獲取相關信息。然而，僅有數(shù)據(jù)庫表的開放是遠遠不夠的，更為重要的是產(chǎn)品要開放相應的對外暴露且可擴展的 API 接口。

大家可以想象一下，如果僅僅開放數(shù)據(jù)庫表，卻沒有與之配套的業(yè)務規(guī)則和邏輯，那會是什么樣的情況？

舉個簡單的例子，雖然數(shù)據(jù)庫表是開放的，但你能隨意地直接連接數(shù)據(jù)庫，往核心表里寫數(shù)據(jù)嗎？

答案顯然是否定的。

因為在正常情況下，任何寫入到正式表的數(shù)據(jù)，都需要經(jīng)過前端一系列復雜的業(yè)務規(guī)則和邏輯控制。如果沒有這些 API 接口，企業(yè)在進行系統(tǒng)集成和數(shù)據(jù)交互時就會面臨諸多困難，甚至會導致數(shù)據(jù)不一致、業(yè)務流程受阻等問題。這樣一來，企業(yè)數(shù)字化建設就會陷入新的困境，形成一個個信息孤島，這與我們推進信息化建設、追求各系統(tǒng)互聯(lián)互通的核心目標是背道而馳的。

就拿我最近和一家選擇了低代碼廠商的甲方公司交流時了解到的情況來說，他們使用的低代碼平臺核心功能確實很強大，但問題在于，通過這個平臺構建的大量業(yè)務模塊或功能，由于缺乏有效的開放性和集成性，反而變成了新的信息孤島，這無疑給企業(yè)的數(shù)字化進程帶來了阻礙。

2. 咨詢和實施顧問能力

其次，在進行產(chǎn)品和供應商選型時，我們不能僅僅關注產(chǎn)品的核心功能及功能特點，還要著重考察供應商派駐到甲方項目中的咨詢顧問和實施顧問的能力。

特別是對于一些像主數(shù)據(jù)、數(shù)據(jù)中臺、傳統(tǒng)的 BI 等項目而言，產(chǎn)品功能的滿足往往只是很小的一部分，它更多地只是作為一個基礎的底層數(shù)據(jù)底座而存在。真正關鍵的是，如何基于企業(yè)的業(yè)務流程進行深入梳理和分析，包括數(shù)據(jù)的建模、元數(shù)據(jù)標準的定義等一系列工作，進而制定出完善的數(shù)據(jù)采集、集成、存儲以及數(shù)據(jù)模型和數(shù)據(jù)能力開放等內容和流程。

這些工作的重要性不言而喻，如果沒有經(jīng)驗豐富的咨詢顧問和實施顧問，企業(yè)往往很難將這些工作做好。

就拿我們自己做的底層平臺DevOps平臺來說也是一樣的道理。很多人對它的認識可能比較簡單，覺得它無非就是開源的各種技術工具鏈的一個簡單集成，提供持續(xù)集成和流水線編排的一些能力。

但實際上，DevOps更多的是體現(xiàn)為一種技術實踐和管理實踐。在實際操作過程中，我們會把核心的研發(fā)管理過程的一些實踐融入到對DevOps產(chǎn)品的實施過程中，而這些實踐經(jīng)驗往往才是項目成功的關鍵所在。

還有一種情況就是甲方在選擇產(chǎn)品和供應商的時候，只認大公司和大品牌。但是實際大公司中標后，往往派駐到客戶現(xiàn)場實施項目的都是剛工作沒有太多經(jīng)驗的顧問或實施人員。你產(chǎn)品即使再好，你沒有經(jīng)驗豐富的咨詢實施人員和現(xiàn)場的項目管理，對于這種IT建設項目也很難取得成功。類似前幾年大量數(shù)據(jù)中臺項目建設失敗或中途夭折就是明顯的案例。

所以，在選型時，供應商的顧問團隊能力絕對不容忽視，他們就像是企業(yè)數(shù)字化建設道路上的引路人，能夠幫助企業(yè)避開各種坑洼，順利抵達成功的彼岸。

3. 產(chǎn)品后期的可運維和可交維能力

最后一個關鍵點是從甲方的角度出發(fā)，在完成產(chǎn)品選型并進入到建設上線階段后，最終必然會進入到相關的運維期和交維期。

因此，在產(chǎn)品選型階段，就必須從后續(xù) IT 運維的復雜度方面進行更多的思考。即便企業(yè)打算找第三方代為運維，這一點也同樣重要。

基于這個考慮，企業(yè)在選擇產(chǎn)品時，應該更多地關注產(chǎn)品在數(shù)據(jù)庫、中間件、開發(fā)框架以及各種技術組件的使用上，是否盡量做到了標準和統(tǒng)一。

曾經(jīng)在去年我和一家甲方企業(yè)溝通時，就遇到過這樣的問題。這家企業(yè)當時整個信息化建設已經(jīng)到了后期，但是我們發(fā)現(xiàn)，在類似于緩存，消息中間件，ETL集成工具這一塊，各個廠商和各個系統(tǒng)使用的工具五花八門。

大家可以想象一下，這種情況會給后續(xù)的統(tǒng)一運維工作帶來多大的困難。不同的工具意味著需要不同的運維知識和技能，運維人員需要花費大量的時間和精力去熟悉和掌握這些不同的工具，一旦出現(xiàn)問題，排查和解決的難度也會大大增加。

所以，對于企業(yè) IT 產(chǎn)品項目的選型，從一開始就必須要考慮其可運維性和可交維性，在數(shù)據(jù)庫、中間件、開發(fā)框架、技術組件等的選擇上，要制定前期統(tǒng)一的框架和標準，這樣才能為后續(xù)的運維工作打下堅實的基礎，確保企業(yè)數(shù)字化系統(tǒng)的穩(wěn)定運行。

總之，企業(yè)在數(shù)字化建設和選型過程中，前期對這三個關鍵點的把握至關重要。只有充分考慮產(chǎn)品的開放性、供應商顧問團隊的能力以及后續(xù)運維的復雜度，才能為企業(yè)打造出高效、穩(wěn)定、可持續(xù)發(fā)展的數(shù)字化體系，助力企業(yè)在激烈的市場競爭中立于不敗之地。

今天的分享就到這里，希望對大家有所啟發(fā)。