在未来应用的出发点上，更多还是在地产或不动产行业看到的项目中很难解决的问题，是不是能有一些新的思路来解决，以及应用现代化也好，或者是AI能力、大模型的能力，如何在里面做一些结合是非常关键的。
实际上做不动产行业，会有企业内部管理的问题，但是这个问题确实不好解决。像有的客户本身业务很复杂，可能有地产、旅发、农业、商业地产的业务，尤其是现在央国企场景下，大家希望有一个统一的平台，进行统一管控，能够把这些业务做关联。但这是超级复杂的，像地产下面有十几个事业部和二十多个公司，农业可能有四五百个基地，面临的组织架构差异、数据标准差异、业务逻辑的差异、审批流程的差异，还有财务规则的差异，是多样化的。实际上这个事情最早是SAP所有东西都归到ERP进行处理，中间2018、2019年开始提出业务中台、数据中台的模式去解决这些内容。但实际上真正做过十个业务中台项目之后都有体会，这个业务中台的设计原则非常好，但是真正到实操过程中，不管是甲方还是供应商对能力要求太高了，没有看到全面的供应商或甲方，既能够梳理业务，又能够把技术架构解决掉，这不亚于一个手术，对大家的能力要求很高。
我们也不断地探索，把东西进行拆解和任务简化，我们提了一个应用模块化设计，其实是把这些复杂的能力分开，分块到不同的角色进行处理，把应用模块化设计分三成个角色做拆解：
第一个角色是创造者，相对来说比较清晰。业务负责人或者业务部门的人配合在这个领域的供应商一起做业务模块的设计。需要两部分的能力：一个是甲方对自己的业务部门的流程和逻辑非常清楚，但也需要和供应商一起看到外面成熟的体系怎么做的，这是两方面需要做结合的。
第二个阶段就是融合者。需要把现在设计好或者要设计的业务模块和其他业务模块做组合，比如我设计了一个流程，这个流程往下走可能要跟合同辅助对接，或者跟财务系统对接。这里面就需要把不同的业务模块和其他业务模块做组合，这个能力现在是由供应商做的，但是未来一定可以和大模型做结合。因为我们会喂给它很多流程编排的规则和内容，实际上这块是交给大模型做未来深度的服务编排能力。
第三块也是我们关心的领域，在这么多业务模块或者这么多可打包业务单元做好之后，对一个集团来说应该把运维化变成公有能力上架，还是把哪个模块单独拎出来跑到集团层面做管控，这其实是一个管理者。管理者的角色，对现有央国企信息部来说，这个模块更多是向应用现代化的标准如何符合对接，或者接口规范设计好之后，由他们做整个模块的上架工作。
应用现代化制定业务模块的设计标准
业务模块的标准也是按照应用现代化的理念做一个设计，其实是在里面会拆分几个方面做设计：
首先，PBC可打包业务模块会由多个供应商的产品做组合，对于供应商的产品定义也好，或者对它来说选型是有一个标准的。其次，在集团层面做了组合之后要有一个能力提升，有收入增加或运营成本的奖励，这是选型的标准。最后，更多地把行业里不同厂商的内容做结合，过程中要不断地做简化，把这些采购过程、实施过程、集成的过程不断做简化，这是对于它的三个要求。
我们也看到在现阶段，把模块按照不同的类型做了拆分，有面向业务场景的应用型模块、也有面向数据分析的数据型模块、还有面向分析工具大模型分析型模块。这三个模块预计在未来几年内，因为行业厂商不断地加入，也由央国企公司不断地引入，会呈现比较强烈的增长趋势。
在智能制造、产业园区、资产管理、国资监管、产城融合、产业运营、资产管理等层面看到还是有非常强的业务拉通和应用模块化设计的一些场景。
