BO业务对象(Business Object，BO)是对数据进行检索和处理的组件。是简单的真实世界的软件抽象。业务对象通常位于中间层。 (更多信息百度：51sap实战中心) 　　业务对象可以在一个应用中自动的加入一个特定的功能来获得增值效应。使知识重用变为可能。比如，如果你要开发一个包含多货币处理的应用，你可以选择使用一个已经开发完成的，包含所有多货币处理功能的业务对象来开始你的开发。使您的开发工作极大的减少。

　　SAP BO的软件和服务可帮助企业：

　　提高运营效率 　　保持公司战略与日常执行的协调一致 　　增强与客户、合作伙伴和供应商的可赢利关系 　　强化自己的产品和服务，使之脱颖而出 　　我们的部分解决方案包括： 　　财务和利润分析 　　管理仪表盘和记分卡 　　市场和销售绩效分析 　　客户和供应商分析 　　人力资源职能的自动化

　　业务对象的必要条件

　　1.由状态和行为组成 　　2.表达了来自业务域的一个人，地点，事物或概念 　　3.可以重用

　　业务对象的分类

　　1、实体业务对象: 　　表达了一个人，地点，事物或者概念。根据业务中的名词从业务域中提取。如客户，订单，物品。 　　2、过程业务对象: 　　表达应用程序中业务处理过程或者工作流程任务。通常依赖于实体业务对象，是业务的动词。作为应用程序的管理者或者控制者。 　　3、事件业务对象: 表达应用程序中由于系统的一些操作造成或产生的一些事件。 (更多信息百度：51sap实战中心)

　　SAP BO业务对象的抽象与整合,业务对象的抽象和整合有何联系呢，或许有人会问我这样的一个问题（以前的我也老想着这个问题），就这个问题我个人觉得,如果脱离业务抽象而想象一个架构体系，那么是一个本末倒置的愚蠢的做法，因为只有做了一个业务的抽象才能根本上满足需求本质，这样才能更实际的充分的得到现实业务现象的抽象才能合理有效的模拟实现的IT系统（一个IT化的过程第一步骤）。

　　整合IT系统面临一个很大问题如何抽象IT系统的交互问题，这个方面IBM采取了消息通信的抽象；它这样做当然有他的道理（也是比较接近现实场景的），但是我在这里顺便提一下我个人的想法，消息其实只是通信和协调的一个实现而已，但是还没有到本质；本质就是通信的协议的定制。我自己采取的就是在底层使用一个会话协议抽象（工作的保密关系不能再细说了，但是我的实践告诉我这样做有很高的架构体系扩展上，大家有机会可以试一试）。 (更多信息百度：51sap实战中心)

　　所以业务抽象十分重要，只有把握好这一点，你的架构系统将体现更高的架构体系高度。你会发现需求的现象的本质，已经没有太多的需求变动能破坏你的架构----除非业务的本质改变了（但这却仅仅说明我们还没有把握业务的本质）。

    上海51SAP教学中心地址：上海徐汇区中山西路2025号永升大厦8楼。咨询电话：400-6571-966   公司品牌价值：让学 员踏入金领行业是我们最大价值

 (更多信息百度：51sap实战中心)

bo培训