數勢科技是企業服務賽道的新勢力，采用新數智技術、新產品理念、新交付范式，結合業務 Know-how，致力于解決企業服務領域中的各種難題和痛點。數勢的主要服務對象包括大金融、泛零售和新智能制造領域的優秀企業，專注于為客戶提供經營決策和營銷相關的數據智能產品。本文將分享金融場景中的指標體系建設思路，希望能夠為大家帶來新的啟發。

一、金融行業指標現狀

1. 指標化經營是企業數據化經營基礎

當前，整個市場已經從流量時代進入了存量競爭時代。特別是在金融領域，經過過去 20 多年的信息化和數字化建設，頭部銀行、證券和保險等典型金融客戶已經積累了海量的數據。然而，如何有效利用這些數據來支持企業的經營、管理和決策，成為了一個亟待解決的大問題。

在這個過程中，指標體系發揮著至關重要的作用。一個理想的企業經營模式是，從企業經營的大目標（北極星指標）出發，將目標拆解到各個部門、員工等業務單元。通過構建一個完善的指標體系，實現金融企業的數字管理模式，將每個部門、每個人的工作緊密串聯起來。以指標作為指揮棒，確保每項工作和每個角色都能形成閉環。

為了實現這一目標，企業需要建立一個統一、準確、高效、集中化管理的指標體系。這不僅是解決當前金融行業痛點的關鍵，也是推動金融企業持續發展的重要保障。

2. 指標是實現企業戰略目標的統一組織語言

在現實環境中，金融行業的建設長期以來依賴于成熟技術，并投入了大量數據科技人才，通過自下而上或煙囪式的方式構建其基礎架構。金融體系已經擁有很好的數字化基礎，積累了龐大的數據量，展現出巨大的潛力。然而，盡管具備這些優勢，金融行業在邁向智能化企業經營理念的道路上，仍然面臨著數據孤島、指標體系不統一以及難以適應業務變化等多重挑戰和問題。

我們抽象出兩個主要問題：數據的混亂和需求響應慢。在過往的金融企業數字化建設中，存在大量煙筒式的系統建設方式。根據對頭部客戶的調研和采訪，大部分企業擁有數百個大小各異的業務系統，部門間的數據口徑和定義存在明顯差異。這種差異在單一部門或閉環業務單元內可能可以通過指標和數據驅動，而一旦涉及集團化管理，部門間的數據口徑對齊就變得極為復雜，需要大量的往復溝通和對齊工作。

此外，基于這樣的數據基礎設施，數據倉庫中包含了大量的模型口徑定義和各種 ETL 任務。在這樣的環境下，業務迭代的周期和響應速度已無法滿足數字化經營的需求。隨著企業規模和數據的不斷增長，這種矛盾將愈發凸顯。

二、痛點->技術問題

1. 痛點分析

從數據的生產和消費兩個維度出發，我們重新理清了當前面臨的主要痛點。

• 在數據的消費端，無論是金融企業還是其他類型的企業，其核心都是管理團隊和業務團隊在進行數據消費。管理團隊主要接觸的是管理駕駛艙，這里的數據通過一系列復雜的數據加工管道和工作流形成，是管理者最為關注的信息。然而，他們面臨的問題在于只能看到數據的表象，卻難以深入探究數據的波動原因或進行下鉆分析。當管理者需要基于數據進行決策時，他們可能會產生各種猜想和假設，但由于數據使用的靈活性不足，這些猜想和假設難以得到驗證，這是管理團隊用數的主要痛點。
• 在數據的生產端，數據加工團隊面臨著海量且復雜的任務。隨著企業規模的擴大，不同部門提出的臨時性報表需求和數據加工需求不斷增加，導致團隊的工作積壓嚴重。更糟糕的是，這些工作往往是一次性的，無法形成企業的數據資產和沉淀，這無疑是一種巨大的資源浪費。這是數據生產者的主要痛點。

2. 痛點具體表述

為了更形象地展現這些問題，我們對從不同企業收集到的典型痛點進行了一定的抽象和匯總，如上圖中所示。

從管理者的角度來看，數據并不直接等同于洞察或決策。他們面臨的挑戰在于如何準確解讀這些數據，理解其背后的深層含義。然而，由于數據是通過一系列復雜的數據加工管道和分析師的人為處理得到的，其中可能會引入一些主觀思考和誤解，導致信息扭曲或損失。此外，數據處理的速度和效率也是數據消費過程中面臨的重要挑戰。

3. 痛點問題抽象

我們觀察到，盡管企業擁有龐大的數據資源，卻未能充分發揮數字化經營的價值。這種供需沖突促使我們深入思考問題的本質。

主流的數據管道和加工模式通常涉及多個環節和角色。決策者和業務人員基于經營理念和邏輯，對數據產生需求，這些需求隨后被轉譯為具體的數據需求，并交由數據分析師處理。數據分析師與 BI 工程師協同工作，將業務需求轉化為 BI 報表需求。BI 工程師再進一步與數據工程師溝通，明確報表對源數據的需求。而這些源數據通常受到數據管理部門的權限控制。經過這一系列定義和管理流程，數據工程師最終從數據源獲取數據，在數據倉庫中進行深度加工，形成數據集市，并最終生成報表，滿足數據需求方。

這一典型的數據加工管道涉及多個角色的交叉協作，流程冗長。其中，關鍵的矛盾在于每個數據交互環節都需要需求提出方和實現者之間進行信息口徑的對齊，不同知識背景的人在溝通中很容易產生信息消耗和損失，需要不斷糾偏，使得這一流程效率低下，并且信息損失、質量問題不可避免。

三、解法

1. 痛點解法（數據右移、角色解耦）

在當前大數據技術、大模型以及生成式人工智能技術迅猛發展的背景下，我們不禁思考：是否有可能實現數據從生產到價值的端到端交付？是否存在一種顛覆性創新方式，能夠縮短各環節流程，甚至使環節參與者變為單一角色？這正是數勢科技一直在探索的解決方案。我們將其定義為“數據右移、角色解耦”，旨在解決行業痛點，實現數據價值的最大化。

金融系統因其與資金緊密關聯，對數據容錯率有著極高的要求。無論是銀行、證券還是保險，每一筆交易都需精確無誤。在數據轉化為決策、決策指導營銷直至決策執行的過程中，數據的準確性和使用精度至關重要，這是行業的共識。

金融體系匯聚了大量具備豐富知識和經驗的業務人才，其知識密集度極高。然而，要求這些業務人員直接理解數據（即“業務知識左移”）確實面臨巨大挑戰，幾乎難以實現。

因此，我們提出了一個創新的解法：通過產品和技術實現“數據右移”。這意味著讓數據建模和解讀更加接近業務人員，使他們能夠直接參與并操作。這樣，數據分析師和 BI 工程師的角色將被解耦，數據消費者能夠更直接地獲取和使用數據的價值。

如果這一路徑得以成功實施，我們將真正實現數據價值的普惠化和民主化，讓“人人用數”成為可能。這將大大提高金融系統的運行效率，同時降低對專業人才的依賴，推動整個行業的進步。

（1）數據語義建在數倉

在技術理念層面，傳統的數據指標加工流程涉及從上游業務系統抽取數據源，存儲到數據湖中，并進一步將數據拉入數據倉庫進行深度處理。在數據倉庫中，執行典型的 DWD（數據倉庫明細層）、DWS（數據倉庫匯總層）以及 ADS（應用數據服務層）等分層建模加工。

建立詳細的數據口徑、權限管理，以及上層對各級各層數據的抽象邏輯，這些都嵌入在數據倉庫的復雜結構中。然而，對于非技術人員而言，這個數據倉庫就是一個黑盒，其內部的復雜性和運作機制難以直觀理解。

盡管如此，這個黑盒的下游是企業 BI 大屏和各種典型數據應用場景。這就是傳統的數據加工模式，它一定程度保證了數據的準確性和可靠運行，但也帶來了技術復雜性、流程的冗長和非技術人員理解上的挑戰。

（2）數據語義建在倉外

數勢科技秉承 HeadlessBI 的理念，這一理念與數智工廠的理念不謀而合，體現了當前企業對于低代碼平臺的共同期待。我們期望通過這一平臺，將數據語義建在數據倉庫之外，即構建一個強大的語義化指標平臺。

借助指標平臺，我們的工作可以更加高效和靈活。在數據倉庫中，我們只需進行基礎的數據加工，如原子指標的構建，而將數據語義和元數據的管理轉移到指標平臺上。這樣，在指標平臺上，可以實現數據的管研用一體化，通過簡單的拖拉拽即可完成指標的加工。這樣企業就可以實現集中化的指標管理。在這一過程中，業務人員和數據管理人員可以直接參與指標的定義、管理和使用，無需依賴傳統的數據分析師團隊。此外，新平臺上的指標加工實現了即用即建，極大地縮短了指標加工的周期，幾乎可以趨近于零。

基于 HeadlessBI 的指標平臺理念，如果設計得當、產品力強大，它將為企業數據消費端的下游應用、Agent 和 BI 等帶來更加便捷的體驗。這不僅是數據價值釋放的關鍵，更是實現數據建模可視化右移出倉的重要步驟。通過這一平臺，業務人員、數據分析師以及其他對數據指標加工和價值釋放有需求的角色都可以直接參與指標的開發，從而提升整個企業的數據驅動能力。

2. 數據建模右移

（1）HeadlessBI 和指標平臺

• HeadlessBI

數勢科技致力于實現 HeadlessBI 和指標平臺的核心價值。這背后的關鍵在于深入理解行業，將產品力抽象至極致，形成易于使用且功能強大的產品。當產品足夠優秀時，使用門檻將大大降低，指標加工將變得優雅而高效。這一過程中，系統的穩定性和指標管理能力都至關重要，它們為未來大模型應用奠定了堅實基礎。我們已成功交付數十家頭部客戶，并發布了行業首份指標平臺白皮書。今年 5 月，我們更成為首家通過信通院認證的指標平臺。

• HME(指標計算引擎)

在服務眾多客戶的過程中，我們面臨一個挑戰：如何在滿足消費端靈活性和速度的同時，降低計算和存儲成本。這構成了一個“不可能的三角”。為解決這一問題，我們打磨出了 HME 指標計算引擎。它確保了我們的產品既具備秒級高性能，又保持優雅的產品能力，同時實現成本、效益最大化。

• OLAP

對于 OLAP 選型，我們基于 Doris 和 StarRocks 進行了深度優化。這一技術路線選擇，確保了我們在大數據處理和分析方面的性能優勢。事實上，我們已通過第三方測試驗證了這一點，相關測試數據在公網上，均可查閱。我們堅信，這一技術基礎將為客戶帶來更高效、更穩定的數據分析體驗。

（2）HeadlessBI 架構

典型的 HeadlessBI 架構分為三層。底層是物理層，利用 OLAP 技術（如使用外表等方式）將物理數據注冊為基礎元數據，并捕獲基礎顆粒度的指標。隨后，通過深度理解客戶業務邏輯和場景需求，實現指標加工的可視化操作，簡化從數據準備到模型構建，再到指標開發的流程。使整個過程是低門檻、優雅且高效的，同時實現集中管理。構建好這一層后，向上提供通用的主流 API 接口，支持 BI 分析、大模型應用以及企業內部的自主數據查詢，為其提供高性能、高并發、高吞吐以及高實時性的指標服務。

為了滿足上述需求，我們服務的客戶數據規模常達 TB 甚至 PB 級別，用戶數量更是數以億計。處理如此龐大的數據量和滿足客戶的復雜分析需求，要求我們擁有高度技術抽象能力的指標引擎，以確保系統的高效運行和數據處理能力。

（3）高性能虛擬計算引擎 V3.0

數勢科技的指標引擎經過三代演進，現已達到 V3.0 階段。最初，我們采用基于  Cube 或者大寬表的傳統方法，這些方法雖能滿足基本的取數需求，但存儲成本高昂，空間利用率低下。隨后，我們深入洞察不同業務和客戶的使用場景，對指標和維度進行了高度抽象，并引入了類似數據集的預計算和預加工技術。這一改進在存儲和性能上取得了顯著的平衡，但靈活性受到了一定限制，并且在某些語義下仍存在數據冗余的問題。然而，我們始終致力于通過技術創新解決這些挑戰，以提供更加高效、靈活且成本效益顯著的數據解決方案。

（4）HMEV3.0 基于 ROI 智能自迭代加速

HMEV3.0，作為新一代高性能指標引擎，采用了基于結果的后置數據預計算策略，實現了基于 ROI 的智能自迭代加速。

這一策略的核心在于，系統通過注冊數據的元數據和使用場景，能夠自動診斷哪些指標在處理時速度較慢或無法及時生成。針對這些問題，系統會對相關數據進行有針對性的調優和預計算。一旦這些計算完成，新的查詢請求到來時，系統會自動改寫查詢語句，利用已完成的預計算結果，從而顯著提升查詢速度。

這種機制實現了企業數據使用的最小化預計算集合，并且具備自迭代能力。隨著企業查詢的不斷進行，系統能夠智能地識別出哪些預計算資源已經不再使用，并釋放這些資源，以保持存儲空間的優化利用。這種智能查詢引擎的引入，使得企業在使用數據時能夠體驗到查詢速度的不斷提升，同時降低空間和存儲成本，這正是我們持續迭代和優化的理想目標。

3. 數據解讀右移

（1）數勢科技 SwiftAgent

在擁有成熟產品和新設計理念的基礎上，再加上底層加速引擎的技術支撐，我們進一步探索數據解讀的右移。在企業中，數據的消費者可能是管理者、業務人員乃至全員，往往面臨一個共同的挑戰：他們可能不熟悉BI 工具，導致這一強大工具在企業中的普及度受限。

然而，還有更多的人并不知道企業內哪些數據能為他們的工作帶來幫助，也不知如何提出和尋找這些數據。即便我們提供了智能助手或與大模型交互的工具，他們也可能因不熟悉而難以利用。

基于對行業痛點的深入理解，數勢科技通過 SwiftAgent 致力于實現數據解讀價值的右移。我們的目標是讓企業的每一位數據消費者都能最大限度地挖掘和利用數據，了解哪些數據對他們當前的工作有益，并將這些數據轉化為知識和決策支持，從而真正發揮數據的價值。

（2）NL2SQL 存在效果瓶頸和性能風險

在當前的行業趨勢中，主流技術思路之一是期望通過自然語言直接轉換為 SQL 或 Python 代碼，以滿足數據查詢需求。用戶可以通過大模型將自然語言描述的數據需求轉化為相應的查詢語句，然后直接從數據倉庫中拉取數據，得到反饋。

然而，根據我們的評估，盡管 NL2SQL 的準確率在調優后，能達到百分之六七十的較高水平，但在實際應用中仍面臨諸多挑戰。首先，生成的 SQL 語句往往缺乏足夠的調優，這可能導致查詢性能低下，甚至無法正確執行。對于復雜的數據加工和計算任務，可能需要預計算支持，而 NL2SQL 系統通常無法直接處理這類需求。

此外，即便能夠生成并執行查詢語句，頻繁的實時查詢也會對企業的存儲和計算資源造成巨大壓力，造成資源的浪費。同時，NL2SQL 技術還需要考慮學習成本、數據安全等一系列問題。因此，雖然 NL2SQL 技術具有一定的潛力和價值，但在實際應用中仍需面對諸多挑戰和限制。

（3）數勢 NL2MQL 之路相比 NL2SQL 優勢

鑒于 NL2SQL 在復雜查詢場景下遭遇的諸多挑戰和限制，數勢科技采取了創新的解法，通過整合指標平臺和智能代理（agent）的能力，成功實現了自然語言到指標（簡稱 NL2MQL）的轉換，再將指標對應到 SQL，這一路徑有效克服了 NL2SQL 的難題。

以復雜的查詢為例，隨著查詢復雜度的提升，NL2SQL 的實現難度急劇增加，甚至在某些場景下變得不可行。而數勢科技的 NL2MQL 方案則通過先將自然語言轉換為細顆粒度的指標語義，再將指標語義轉化為 API 請求，最后通過指標平臺調用取數 SQL，這一過程不僅確保了查詢的準確性和高效性，還使得大模型的數據解讀能力得以商業化落地。

數勢 NL2MQL 的優勢在于其能夠更精準地理解用戶的查詢意圖，將自然語言轉化為更符合業務邏輯的指標語義，進而通過高性能的指標平臺快速生成并執行 SQL 查詢。這種兩段式的處理方式不僅提高了查詢的準確性和效率，還降低了對存儲和計算資源的消耗，為企業帶來了更大的商業價值。

此外，數勢 NL2MQL 還具備高度的靈活性和可擴展性，能夠輕松應對不同行業和不同場景下的數據查詢需求。通過不斷的優化和迭代，數勢科技將繼續推動 NL2MQL 技術的發展，為企業提供更高效、更智能的數據分析和決策支持。

（4）指標平臺+大模型，實現數據價值的端到端

通過多個客戶的 POC 驗證和交付實踐，我們已經充分展示了指標平臺與大模型結合后所帶來的強大能力。這種結合使得數據質量和問題回答的準確率幾乎達到了數據質量的上限，同時顯著提升了性能，降低了學習成本，并確保了數據安全。

在指標平臺上，我們深入整合了數據的權限管理功能。通過與企業的組織劃分、人員權限標簽等系統緊密連接，我們能夠實現從表、緯度、指標乃至更細顆粒度的權限控制。這種精細化的權限管理確保了數據的安全性和合規性，同時為企業提供了更加靈活和高效的數據使用方式。

（5）Agent 架構運轉流程

我們的產品中的 Agent 是一個典型的多智能體解決方案。通過運用 TOT（Task Oriented Thinking）和 COT（Conversation Oriented Thinking）等先進的 Prompt 工程技術，Agent 能夠精準地拆解問題，并實現協同決策。

在運作過程中，Agent 會充分利用之前提到的指標平臺，高效地調用相應的 Actions，獲取數據后進行后驗推理，并將結果準確、及時地呈現給客戶。這一流程確保了數據處理的準確性和高效性，為用戶提供了卓越的使用體驗。

（6）數勢科技 SwiftAgent 流程圖

這是數勢科技 SwiftAgent 的一個典型請求流程圖。當用戶發出請求時，系統首先接收并處理這一請求。值得一提的是，我們采用 RAG（知識圖譜構建方法）的方式，將企業的知識庫無縫集成，確保企業內部指標口徑的語言或工作語言習慣與指標平臺保持一致，為大模型提供友好支持。

隨后，經過大模型的處理，請求會流轉到工具調用部分。在這里，結合前面提到的指標語義平臺，我們能夠實現足夠細顆粒度的 API 調用，確保數據的準確性和高效性。整個流程的設計旨在為用戶提供卓越的使用體驗，同時確保數據處理的高效和準確。

（7）數勢科技 SwiftAgent 創造性解決 5 大挑戰

借助指標平臺與數勢科技研發的 Swiftagent 多智能體產品能力，我們成功實現了從數據生產到數據消費的端到端的數據價值流轉，創造性地提出了應對五大挑戰的解決方案。

首先，針對分析準確性的挑戰，我們認識到大模型在轉換為 SQL 或代碼時準確率不足，這限制了產品的實用性。因此，我們利用指標和標簽的語義化產品，以及數據虛擬化技術，實現了數據價值的右移，從而顯著提升數據分析的準確性。

其次，數據全面性是另一個重要挑戰。為了深入理解企業數據的語義，我們整合了多源異構數據，包括結構化和半結構化數據，以及企業內部知識庫。這一舉措有助于我們更全面地理解企業的數據結構。

在人機融合創新方面，我們通過 SwiftAgent 產品的精細工程化，為用戶提供了智能的數據推薦和洞察。無論用戶是數據的消費者還是新手，我們都能通過權限管理、模糊提問、反問和追問機制等，幫助用戶澄清問題，降低數據使用的門檻，釋放更大的數據價值。

此外，我們的模型還具備持續反思、積累和迭代能力，這是實現產品不斷優化和進步的關鍵。

最后，面對 LUI 交互模式下靈活取數的需求，我們引入了指標預計算 HME 技術。這一技術能夠確保在足夠靈活的取數場景下，仍然保持高性能的響應速度。通過這一技術，實現了企業數據價值的普惠化，讓每個人都能輕松使用數據。

四、指標產品合作案例

1. 某頭部證券公司基于指標平臺的經營分析平臺建設

該案例涉及的是數勢科技與某頭部券商的合作，該券商在數據分析領域遇到了多個典型問題，包括分析準確性、數據全面性、人機融合創新等方面的挑戰。數勢科技通過其指標平臺和 SwiftAgent 產品，為該券商提供了端到端的數據價值流轉解決方案。

2. 80% 的新增指標不依賴數據人員

隨著我們的第一代和第二代指標平臺相繼成功實施，企業內部約 80% 的指標開發工作已經實現了通過拖拉拽式的零代碼開發，直接由業務人員完成。這一過程中，平臺提供了沖突檢查以及指標全生命周期的質量管理功能，確保數據的質量與準確性。

同時，我們將剩余約 20% 更為底層和復雜的數據工作交給了專業的數據工程師團隊。他們運用自己的技術能力，專注于數據倉庫的質量管理、生命周期維護以及更深層的數據管理，從而進一步提純數據的價值。

這種分工方式使得整個數據處理流程更加高效，縮短了管道、流程和時間，確保數據能夠更快速、更準確地為企業創造價值。

3. 面向業務人員的 BI 分析產品，隨時隨地修改卡片

基于這樣一個可以靈活取數的指標平臺，當下游 BI 產生新的數據使用需求時，業務人員可以直接在指標平臺上通過簡單的拖拉拽操作，快速配置所需的數據。

4. 面向業務場景，低門檻靈活組裝個性化看板

此外，指標平臺還支持多種低門檻、靈活的組裝方式，幫助業務人員輕松構建出各類指標的看板，實現數據的可視化展示和深度分析。

5. 支持業務同學對話式進行數據分析，更好的智能化交互體驗

通過 SwiftAgent 的強大能力，我們實現了數據使用的零門檻，讓業務人員能夠輕松上手。

最后進行一下總結，數勢科技始終秉持客戶、用戶至上的理念，通過技術和產品的創新，站在數據消費者的角度，為客戶、用戶提供端到端的解決方案，真正解決他們在數據使用上的難題。我們誠摯地歡迎感興趣的同行共同探討，期待通過我們的共同努力，讓數據的價值實現真正的民主化、普惠化。感謝大家的關注與支持！

五、Q&A

Q1：請問方便說一下 agent 的底座模型是什么？自研還是開源？參數量級是多少？

A1：在國內，當涉及到大模型的部署，特別是面向 ToB 企業時，我們通常會遇到私有化部署的需求。在這個方面，我們與百川、智普緊密合作，共同探索和創新，以滿足企業的特殊需求。然而，隨著市場競爭的加劇和價格戰的到來，我們注意到一個明顯的趨勢：越來越多的客戶開始接受并傾向于使用大模型的 API 服務方式。

為了順應這一市場變化，我們也積極適配了各大主流平臺，如通義、文心以及 OpenAI 等，以確保我們的服務能夠覆蓋更廣泛的客戶群體。無論是選擇私有化部署還是 API 服務方式，我們都致力于為客戶提供最優質、最符合其需求的解決方案。

Q2：指標 Agent 在人效提升上有什么樣的促進？比如讓每個崗位更好地創造價值，而不是像工具人的值指標對齊。

A2：指標 Agent 在人效提升上起到了至關重要的作用，它不僅僅是對齊指標的工具，而是每個崗位創造價值的強大助手。正如我之前提到的，ChatGPT 這類聊天工具在處理通識性的問題時表現出色，但當面對專業性問題或期望其替代我們完成工作時，其能力便顯得捉襟見肘。這正是 NL2SQL 等技術在應用中遇到的困境，盡管它們有著一定的準確率，但遠未達到可以直接應用于工作的程度。

然而，通過引入指標平臺和 Agent 的結合，我們得以跨越這一障礙。這種方案不僅確保了數據的準確性達到了數據質量的上限，而且真正地對我們的工作產生了實質性的幫助。Agent 不再是一個簡單的工具，而是成為了我們工作的延伸，它告訴我們數據的價值，并幫助我們將這些價值轉化為知識和決策，進而形成企業的寶貴經驗。

對于不同的角色——新員工、資深員工、專家以及管理者——他們對數據的解讀和洞察能力各不相同。但大模型的引入使得我們可以將企業的知識庫與之掛接，讓這個大模型在企業的應用中不斷學習和提煉，變得越來越聰明。這不僅僅是一個數據分析的專家在訓練 Agent，更是一個企業在訓練自己的數據分析專家。這樣的專家不再局限于某個特定的崗位，而是可以為每個需要數據的員工提供服務，即使他們不擅長提出專業問題，Agent 也能幫助他們最大化地利用手頭的數據資源。

因此，指標 Agent 的引入不僅僅是提升了人效，更是將數據的價值最大化、普惠化，幫助企業從數據中獲取更多的洞察力和決策依據。這個過程已經超越了簡單的效率提升，而是為企業的整體發展注入了新的動能。