歷年來IT信息化建設由業務驅動主導的模式，這個模式在數字化很難行得通，更別說智能化了，但多年來的習慣要改變很難，甚至這個習慣還在延續，看看現在我們做的很多數字化的建設，絕大部分還是在做報表、看板、問題發現，是利用大數據的技術提供常規業務功能，能讓這些報表、看板的信息更全面、更及時；能讓問題的發現更提前、更全面，等，本質上還是業務Owner想看，還是需求拉動的數字化基本技術的使用。

不是說需求拉動就是問題，但公司需要競爭力，才能有希望在市場競爭中獲得生存機會，而需求拉動，很難產生重大變革，很難對公司的競爭力產生重大影響。IT若還是以需求驅動為主，那它就成為不了公司數字化轉型的戰略力量，這個公司的數字化轉型也基本遙遙無期。

IT必須要制定技術賦能業務的競爭力的規劃，要找到技術和業務的競爭力結合部，既能讓當前的業務KPI得到大幅提高，遠超業務需求拉動的建設成果，獲得業務領導信任和支持，又能讓公司產品的競爭力提升，成為公司產品特征的一部分，從而成為公司愿意持續耕耘的賽道，也能讓公司數字化、智能化建設成為常態。

是不是有點天方夜譚？太難了，接下來就是我的胡思亂想了。

咱們把業務縮小到汽車供應鏈業務，找找規律。首先無論業務需求怎么提，業務的基本管理就是PDCA，即Plan、Do、Check、Action，其次汽車供應鏈業務的KPI聚焦于降本增效，如產銷之間的交付滿足率、單車制造成本，管理也是圍繞這些KPI進行PDCA，具體來講：

● Plan

P就是年初對這些KPI制定相比于往年更進一步的指標；

● Do

D就是各個基地按照產銷計劃在精益制造管理體系上進行制造，這是供應鏈體系的大協同，包括了我們和各個零部件供應商及配套服務商，如運輸服務商；

● Check

C就是專門負責檢查KPI等指標實際狀態的工程師們的工作，利用各類信息化和數字化工具來全面檢查，報表、大數據看板、各類例會等；

● Action

A就是物流部、質保部、ME、采購部等眾多工程師的解決問題的工作，因為汽車制造的復雜，即使有強大的體系支持，信息化支持，但還是會有預想不到的事件發生，產生損失產能、質量溢出等問題，影響KPI實現，急需解決，這時候需要大批的問題解決人員，用經驗來制定行動方案來快速解決問題。

所以PDCA是業務固定的幾個階段，圍繞每一個KPI，都有自己的PDCA，而KPI，因為有層層分解，所以有公司級的、板塊級的、部門級的、崗位級的，數量極大，業務的運作，實際上可以理解為極大數量的KPI的PDCA交織在一起，就像巨大的燒水壺，一直沸騰。

從PDCA各個階段的投入人員，A一定是最多的，看看這些部門的崗位設定和工作實際，就可以判斷，所以KPI是否能實現，負責A的工程師們是最關鍵的。

在業務驅動的IT建設中，PDCA的信息化程度如何？D是最多的，C其次，P有一些，而A應該是最少的，因為人員多且來自各個部門，沒有明確的業務Owner，也就沒有業務需求，所以也就沒有信息化建設，更別提數字化、智能化了。當D和C獲得每年的關注，不斷獲得建設投入的時候，A卻被冷落了，而A卻是業務人員最多的、靠每個人的經驗的、沒有基本信息化支撐的、和KPI密切相關的、成本和效率不受控的，簡直就是吃的是草，產出的是奶啊。A才是更需要信息化、數字化和智能化支撐的階段，只有這樣，才能提煉出問題的根源，去完善P、完善D、完善C，才能真正意義上把PDCA形成閉環，試想一下這個場景：營銷的一個提前要車，會涉及到眾多零部件的需求變化，該如何把變化轉化為成本、時間影響最小的行動步驟，來引導自動化的、或者和人工合作半自動化模式的執行，以規定步驟、規定時間來執行，這個效率是否遠勝于人工憑經驗來解決。再試想另一個場景，零件報廢率高，A階段的人分析下來根源是裝配步驟的問題，那就可以在D的信息系統上加上正確裝配步驟的提示，并在該工位的屏幕上用視頻的方式提示，從而讓操作工快速理解，按照正確的步驟裝配，大幅降低報廢率，又把信息提供給該工段的質檢臺，從而提示該信息并要求有一段時間針對性的檢查，這就把問題的解決措施和C和D都進行了比較完美的結合。

PDCA四個環節的信息化、數字化及智能化相輔相成，齊頭并進，才能把可能發生的問題發現在源頭，最快時間解決，從而大幅減少A的投入，也能最大限度地保持高交付率及制造的精益性，從而可以把準時快速交付作為我們產品的特征，也可以把穩定的高質量作為我們產品的特征，從而提升產品的競爭力。

所以基于PDCA管理機制，我們把信息化、數字化和智能化和該機制結合起來，優先布局A環節，應該有機會大幅提升KPI，也能提升供應鏈賦予產品的競爭力。

A的場景，在交付類型的業務，就是解決執行過程中的問題，即高效解決問題，穩定交付，在產品類型的業務中，就是解決產品用戶使用過程中的問題，即高效服務運營，穩定口碑。

那么對于A，數字化和智能化的方案是什么？從場景分析如下幾步：

1. 問題推送和接收，需要考慮問題信息如何讓接收者快速理解，而且大家都能一致的理解；
2. 問題的推送對象，如何準確？這對解決效率及成本控制都很重要；
3. 如何匯聚有利于該問題解決的相關知識；
4. 如何方便問題接收者開展協同工作，快速聯系協作伙伴，快速溝通，如線上會議，快速形成溝通紀要，并按照What、Who、When進行任務拆分、精準推送、時間管理、狀態收集；
5. 如何判斷問題解決，需要關聯D和C的系統，真實獲取解決狀態；
6. 問題關閉，形成問題報告，度量解決效率，更新知識，更新人員績效。

以上這些步驟，快速、精準是成功的關鍵。

逐個分析每一步，我們發現，這對現有的技術平臺提出了很多挑戰：

1. 技術平臺需要能敏捷響應新需求；
2. 技術平臺要能快速的與已有系統（特別是核心業務系統）做數據對接；
3. 需要能對企業的業務知識進行智能的生成、存儲和檢索。

要應對這些挑戰，我們需要使用合適的產品或技術。在這里我主要推薦兩個：

1. Mendix 低代碼開發平臺，使用模型驅動的開發方法和可視化編輯器幫助企業快速開發應用，能敏捷響應新需求。Mendix內置豐富的連接器，支持與企業內外各系統進行實時數據同步，從而實現與核心業務系統的快速數據對接。它可以用來應對前兩個挑戰。
2. 以 ChatGPT 為代表的 LLM 技術，它是一種以神經網絡深度學習為基礎的自然語言生成模型。它可以對人工智能訓練用的海量文本數據進行分析理解，學習企業內的業務知識與術語，然后對這些知識進行智能的生成、存儲和檢索。 它可以用來應對最后一個挑戰。

企業數字化轉型是一場萬里長征，路上荊棘遍布。許多企業陷入需求驅動的誤區，難以取得突破。要找到發力點，企業IT部門必須放眼長遠，主動出擊，并尋找技術與業務的結合點。  希望通過以上思考和建議，能為企業數字化轉型的長征添磚加瓦，起到拋磚引玉的作用。數字化轉型，盡在起點！