在未來應用的出發(fā)點上，更多還是在地產(chǎn)或不動產(chǎn)行業(yè)看到的項目中很難解決的問題，是不是能有一些新的思路來解決，以及應用現(xiàn)代化也好，或者是AI能力、大模型的能力，如何在里面做一些結(jié)合是非常關鍵的。
實際上做不動產(chǎn)行業(yè)，會有企業(yè)內(nèi)部管理的問題，但是這個問題確實不好解決。像有的客戶本身業(yè)務很復雜，可能有地產(chǎn)、旅發(fā)、農(nóng)業(yè)、商業(yè)地產(chǎn)的業(yè)務，尤其是現(xiàn)在央國企場景下，大家希望有一個統(tǒng)一的平臺，進行統(tǒng)一管控，能夠把這些業(yè)務做關聯(lián)。但這是超級復雜的，像地產(chǎn)下面有十幾個事業(yè)部和二十多個公司，農(nóng)業(yè)可能有四五百個基地，面臨的組織架構(gòu)差異、數(shù)據(jù)標準差異、業(yè)務邏輯的差異、審批流程的差異，還有財務規(guī)則的差異，是多樣化的。實際上這個事情最早是SAP所有東西都歸到ERP進行處理，中間2018、2019年開始提出業(yè)務中臺、數(shù)據(jù)中臺的模式去解決這些內(nèi)容。但實際上真正做過十個業(yè)務中臺項目之后都有體會，這個業(yè)務中臺的設計原則非常好，但是真正到實操過程中，不管是甲方還是供應商對能力要求太高了，沒有看到全面的供應商或甲方，既能夠梳理業(yè)務，又能夠把技術(shù)架構(gòu)解決掉，這不亞于一個手術(shù)，對大家的能力要求很高。
我們也不斷地探索，把東西進行拆解和任務簡化，我們提了一個應用模塊化設計，其實是把這些復雜的能力分開，分塊到不同的角色進行處理，把應用模塊化設計分三成個角色做拆解：
第一個角色是創(chuàng)造者，相對來說比較清晰。業(yè)務負責人或者業(yè)務部門的人配合在這個領域的供應商一起做業(yè)務模塊的設計。需要兩部分的能力：一個是甲方對自己的業(yè)務部門的流程和邏輯非常清楚，但也需要和供應商一起看到外面成熟的體系怎么做的，這是兩方面需要做結(jié)合的。
第二個階段就是融合者。需要把現(xiàn)在設計好或者要設計的業(yè)務模塊和其他業(yè)務模塊做組合，比如我設計了一個流程，這個流程往下走可能要跟合同輔助對接，或者跟財務系統(tǒng)對接。這里面就需要把不同的業(yè)務模塊和其他業(yè)務模塊做組合，這個能力現(xiàn)在是由供應商做的，但是未來一定可以和大模型做結(jié)合。因為我們會喂給它很多流程編排的規(guī)則和內(nèi)容，實際上這塊是交給大模型做未來深度的服務編排能力。
第三塊也是我們關心的領域，在這么多業(yè)務模塊或者這么多可打包業(yè)務單元做好之后，對一個集團來說應該把運維化變成公有能力上架，還是把哪個模塊單獨拎出來跑到集團層面做管控，這其實是一個管理者。管理者的角色，對現(xiàn)有央國企信息部來說，這個模塊更多是向應用現(xiàn)代化的標準如何符合對接，或者接口規(guī)范設計好之后，由他們做整個模塊的上架工作。
應用現(xiàn)代化制定業(yè)務模塊的設計標準
業(yè)務模塊的標準也是按照應用現(xiàn)代化的理念做一個設計，其實是在里面會拆分幾個方面做設計：
首先，PBC可打包業(yè)務模塊會由多個供應商的產(chǎn)品做組合，對于供應商的產(chǎn)品定義也好，或者對它來說選型是有一個標準的。其次，在集團層面做了組合之后要有一個能力提升，有收入增加或運營成本的獎勵，這是選型的標準。最后，更多地把行業(yè)里不同廠商的內(nèi)容做結(jié)合，過程中要不斷地做簡化，把這些采購過程、實施過程、集成的過程不斷做簡化，這是對于它的三個要求。
我們也看到在現(xiàn)階段，把模塊按照不同的類型做了拆分，有面向業(yè)務場景的應用型模塊、也有面向數(shù)據(jù)分析的數(shù)據(jù)型模塊、還有面向分析工具大模型分析型模塊。這三個模塊預計在未來幾年內(nèi)，因為行業(yè)廠商不斷地加入，也由央國企公司不斷地引入，會呈現(xiàn)比較強烈的增長趨勢。
在智能制造、產(chǎn)業(yè)園區(qū)、資產(chǎn)管理、國資監(jiān)管、產(chǎn)城融合、產(chǎn)業(yè)運營、資產(chǎn)管理等層面看到還是有非常強的業(yè)務拉通和應用模塊化設計的一些場景。
