这里的所谓系统“集成性”，既非指“技术层面”的集成，也非指模块“应用层面”的集成，而是指企业管理发展过程中内在“核心要素”的集成。有人以为，一个ERP产品所包含的模块数量足够多、企业上线的模块数量足够多，就意味着“集成性”高，这实际上是一种误解。
一个企业从小到大的发展壮大过程，在不同阶段企业管理所要关注的重点因素是不同的。我们常说企业大则有规模经济效益，但实际上企业规模愈大，相应的管理成本也在急剧上升，如果因规模扩大而获得的生产率的提高，不能超过或抵消因规模扩大而导致的管理成本的升高，则就是所谓的“做大但没有做强”。有些人抱怨国外产品（SAP/ORACLE）系统刻板、流程僵化，这实际上是不懂企业管理精髓的外行话。想想看，尽管我们经常取笑国外大公司做事拖拉、流程死板、官僚主义，是资本主义的“国企”，但实际上这些大公司的“生产率”（以人均营收或人均公司GDP计）常十倍于国内同行业。所以说，管理的标准化、流程化是企业发展的必然选择。
一个高度集成的应用产品系统要适应企业管理的发展需要，必须同时考虑以下三大核心要素：数据集成、流程集成、管理集成。但需注意的是，这三大核心要素对于前述企业三大管理领域“财务、业务、事务”的影响与侧重点是有所不同的。
所谓“数据集成”比较好理解，即通常所说的“消除信息孤岛”是也。它可以分为两个方面：“静态数据共享”与“动态数据传递”。“静态数据”主要指类似“物料、供应商、客户”等基础数据，由各模块调用共享；“动态数据”则主要指诸如“采购订单、制造工单、销售订单、发票”等随时间不断累积的业务数据，它们之间需要遵循一定规则进行数据传递。
相较于传统的手工业务模式，现代的计算机技术与数据库技术在解决企业管理“数据集成”方面易如反掌。在系统“静态数据共享”方面国内外产品差距不大，但在系统“动态数据传递”方面，由于有些国内主流产品采取的是“模仿手工单据”的实现方式，导致数据冗余，传递、同步非常困难，使用效果非常糟糕。
ORACLE产品在“数据集成”方面有一个突出的“亮点”是各模块几乎都有集成第三方系统的接口（API），其内部各模块之间的数据集成也基本上采取类似集成第三方系统的“松耦合”方式。有人将之认作是ORACLE比SAP灵活、易用的优点。这可能是与ORACLE产品早期还不完善时，不得不考虑所谓“最佳配置实施方案”有关（详情见“ORACLE ERP的前世今生”有关内容）。这也许可以说是ORACLE的“因祸得福”。
所谓“流程集成”也可以分为两个方面：“流程传递的自动化”与“流程识别的自动化”。ORACLE在其产品宣传中经常讲到一点“用户只需很少的干预与击键操作，其它都由系统自动替你完成”，说的正是这个意思。
所谓“流程传递的自动化”，例如ORACLE“内部申购”，如果是向其它公司的库存组织申请物料，则该采购申请PR被自动导入OM，OM发货后循发运网络被接收，系统自动在两公司间生成应收、应付。再如OM中的直接发运（Drop shipment）物料，系统自动生成PR，客户收货后，一旦PO作接收，则OM系统自动作发货确认并生成AR等。
所谓“流程识别自动化”，ORACLE系统通过大量的“参数”设置（SAP的参数设置有七、八千，ORACLE也不遑多让），使得不同的物料、业务类别，在各模块间循不同的业务流程自动得到相应处理。这无疑使得单个用户在面对大业务量且流程复杂的情况下能够轻松应对，应付自如，获得高的生产率。
参数多，设置复杂，令人生畏，实施困难，向来是SAP R/3产品早年开始就一直遭不少人诟病的地方。ORACLE的实际情况不比SAP好多少，但ORACLE产品作为后来者，在系统流程“参数”设计的层次性、使用的方便性方面，还是做了很多努力，相对而言可能要比SAP容易掌握一些。ORACLE在系统业务流程方面相较于SAP也做了一些简化，但这种“简化”往往是以牺牲某些不怎么常用或使用意义不大的“功能”为代价的。这或许正如有人评价的：SAP求严求全，ORACLE求实求用。现代企业管理的发展方向是追求企业管理的整体效益，要求业务流程简化、再简化，因此ORACLE的做法还是符合潮流的。
曾经碰到一位国内产品的设计人员，对于SAP/ORACLE通过复杂的参数设置以控制业务流程的做法，该仁兄颇为不屑、不以为然：“参数设置已经过时，未来的方向是工作流”。这种说法委实不敢苟同，实际上，ORACLE产品内同时也大量使用“工作流”技术（Workflow），但它与“参数”设置并不冲突，两者是相辅相成的关系。
在企业管理实践的核心“业务+财务”领域，系统的“数据集成与流程集成”的重要性是怎么强调也不过分。在“财务”领域，系统的数据集成是重点，因为该领域流程本来就不是很复杂（这也是应用软件厂商多财务出身，企业信息化也往往先从实现财务电算化开始的原因）。而在核心“业务”领域，系统的流程集成是重点，因为该领域业务环节多、流程长，涉及部门与人员众多，只有实现高度的流程集成才能达到高的生产率。ORACLE的产品之所以强大（当然还有SAP），正是首先在于其核心“业务与财务”系统内部及相互之间的高度的数据集成性与流程集成性。
纵观国内ERP使用比较成功的企业，诸如联想、华为、中兴等，无不是以SAP或ORACLE的核心系统搭建自己的企业信息化平台，原因就在于外围系统（非核心系统、事务管理系统）可以策略性地使用第三方系统或干脆自己开发，但“核心系统”基于数据与流程高度集成性的要求则别无选择（尽管必须忍受高昂的License价格）。反过来从产品研发角度看，核心系统也是不可能通过收购或集成第三方产品取得成功的，ORACLE过往所收购的补充性质的应用产品几乎全是外围或周边应用产品（同类产品收购看重的仅仅是市场份额）。
需要强调指出的一点是，这里所讲的系统“流程”不是指一般意义上的企业管理“过程”。所有的ERP产品都有所谓“流程”，所有的顾问、咨询人员都在给企业大讲特讲所谓的“流程”。但此流程非彼流程，有些产品中的所谓“流程”可能只是无甚管理意义的“过程”而已。前两年有一位国内厂商的咨询顾问在某地公开演讲时，曾发高论：企业管理流程是由“销售计划、采购计划、生产计划”这三大计划驱动的。此论一出，立刻有业内人士斥之为“混淆概念、误导企业”。
京城有一位出身草根、创业传奇的民营企业家，靠摆摊卖包子起家做成一餐饮集团，其在使用了国产ERP后曾评价道“除了把数据归到了一起，没看到有其它好处”。真是奇人奇语，一语道破国内产品的问题所在。细究其原因，就在于国内主流产品普遍都采取“模仿手工业务过程”的系统实现方式，丢掉的是“计算机技术与数据库技术”的长处，彰显的是“手工业务操作”的短处，实现数据集成还能对付，要实现业务流程的“高度集成”，则几无客观上的可能。目前国内主流产品的系统实现与手工操作相比，工作效率的提高有限，有时甚至比手工操作更不方便，因而也无法适应于业务量大、流程复杂的大企业的使用需要。
不过，对于许多中小企业来说，由于规模有限、业务量相对较小，规范但欠灵活的流程管理并非其核心竞争力所在，能做到“数据集成”就可以了（有次在网上与前SAP中小企业市场负责人黄骁俭讨论时，他也感叹，中小企业的管理确实不靠什么流程）。此时，“模仿手工业务操作”的系统实现方式所天然具有的“学习上手容易，实施比较简单”的特点就凸显了。当前中低端市场的国外产品如SAP的SBO、微软的Navision，系统业务流程简单也是它们的共同特点，不过，相较国内产品，它们还是抛弃了很多“手工操作”与“系统实现”相冲突的东西，因而，系统流程的业务效率比纯粹的手工操作还是有明显改善。
最后，来谈谈所谓应用系统的“管理集成”问题。这里的所谓“管理集成”主要是针对非核心业务或其它“事务”性工作领域，系统所能提供的“管理与控制”而言。这些领域工作的共同特点是，不象核心的“业务/财务”领域那样与“实物流”（价值增值）、“资金流”（价值实现）紧密相关。有很多人在学习ORACLE（或SAP）时，都曾会有一个疑问：新增物料、新增供应商、新增销售订单等等，系统的标准操作功能几乎都不考虑这些数据是怎么来的过程问题（例如“单据审批、流程审批”等），实际情况肯定不是这样的吗！为什么核心系统的有些单据界面感觉纯粹只是提供一个“最终结果”的录入功能？
原因在于ORACLE/SAP核心业务/财务系统“以价值为中心”（物与资金都属价值）的应用架构设计，本来就不擅长于处理“以关乎人或组织的行为信息为中心”的事务过程。世上有没有“两者”处理同时都很擅长的应用系统呢？迄今为止还没有出现，鱼与熊掌不可兼得。也就是说针对核心系统，为了保证数据与流程的高度集成性，必须适当牺牲系统的“管理集成性”。为了弥补核心系统的这一不足，ORACLE/SAP提供了大量的外围系统（非核心业务或事务领域）供用户选择使用。
例如“新增物料”过程管理，EBS有“Advance Product Catalog”产品可以提供支持；“新增供应商”过程管理，EBS R12 已经增加提供了基于WEB的某些新功能，相信未来会逐步丰富完善并独立出类似SAP SRM的产品；至于OM中的销售订单，属于CRM的很多模块都是其前端产品，都在为其提供支持与服务。非核心的外围产品由于它们与核心系统在“数据与流程集成性”方面的要求相对较低，故在系统设计时可以更多地考虑系统的管理集成性。这些外围系统通常还有一个共同特征，就是尽可能采用比较适合处理“需要多人参与的信息传递与管理过程”的WEB界面方式。EBS R12中将供应商及客户定义的GUI界面改为WEB界面，单纯从数据录入（集成）角度来看或许并不更方便易用，但却为系统向强调“管理集成”的事务领域扩展打开了方便之门。
前面曾经谈到对于制造型企业非常重要的“质量管理QA”功能，ORACLE核心业务模块中可以不用把它包括在内，而实际上用过“QA”模块的人都知道：它主要只是起到一个收集或录入质量数据的最终结果，并基于录入的结果数据在核心业务流程的某些节点起到某种控制的功能。至于企业所关心的这些质量数据的最终得来要经过怎样的一个复杂事务过程，系统基本不涉及（SAP的QA模块情况类似）。之所以会出现这种状况，是因为“质量管理过程”从系统实现角度来看，基本与“价值增值与价值实现”这两大核心业务过程关系不大，标准产品的规划设计时必须有所“取舍”，否则可能效果适得其反。所以，企业通常需要根据自己的实际情况寻求另外的“基于质量过程管理”的解决方案来配合使用。而人力资源HRM模块与企业核心业务过程的关系也离得比较远，集成性要求并不高，故通常在系统实施优先级方面也可以放得更后一些。
基于“信息与行为”的事务过程管理，各行各业、不同企业的习惯做法或制度规定差异很大，客观上进行系统标准化难度甚大。早些年有人鼓吹自己的ERP产品对ISO9000如何支持（这等“俗事”ORACLE以前也曾干过），前些年有人鼓吹对欧盟的ROHS如何支持，近年又有人鼓吹对“萨班斯法案”如何支持。很难想象这种所谓的“支持”从系统实现的角度来看有多少现实意义。基本上只是“投企业所好”，当不得真。如果有ERP厂商自己先信以为真，则结果必然是缘木求鱼。
由于非核心的业务系统、事务管理系统，与核心的业务/财务系统在“数据与流程”两方面，集成性、紧密性的要求并不是太高。尽管ORACLE/SAP均有很多的类似外围产品，也尽力鼓吹、游说企业只使用其同一家的所有产品，以达到应用系统高度的“管理集成性”，但很多企业还是乐于使用第三方产品或自己开发（License 价格太贵也是重要考虑因素），原因就是完全使用一家的所有外围产品于实际的使用效果或管理效益，很多时候综合优势并不明显。
近年来，电子商务大行其道，国内新锐的IT企业如腾讯、百度、阿里巴巴等纷纷投身介入，如果这些企业能够认识到，ORACL/SAP目前所采取的以单个企业为中心，连接供应商与客户，向上下游延伸、通吃的所谓“大企业”应用全程电子商务战略，因存在先天缺陷而历经多年却发展缓慢，ORACLE/SAP自我革命动力不足，市场客观上正期盼出现突破性的新电子商务应用模式，在精研ORACLE/SAP的核心系统及外围系统的基础上，能够做出与ORACLE/SAP核心业务系统在“数据集成性、流程集成性、管理集成性”方面并不比它们的自身产品差，更符合国内市场且体现中国特色的外围电子商务产品，则介入范围广大、利润丰厚的高端企业应用市场并非没有可能。而核心的ERP产品目前看来还只能是期待国内的传统厂商能在高端领域有所突破。