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

因此今天準(zhǔn)備聊下企業(yè)數(shù)字化選型中的三個(gè)關(guān)鍵點(diǎn)。

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

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

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

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

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

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

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

答案顯然是否定的。

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

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

2. 咨詢和實(shí)施顧問能力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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