189 8069 5689
工作流
站在用户的角度思考问题，与客户深入沟通，找到吴忠网站设计与吴忠网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：做网站、网站制作、企业官网、英文网站、手机端网站、网站推广、空间域名、网站空间、企业邮箱。业务覆盖吴忠地区。
系统关于工作流的设置工作包含两部分工作，一是基于企业的特殊需要，使用Workflow Builder软件包工具自定义工作流。详情需参考ORACLE的相关文档，这里不赘述。二是为系统设置工作流管理员。系统在安装后的初始化工作流管理员是系统超级用户SYSADMIN，企业应当首先使用SYSADMIN进入系统，将工作流管理员改为一个真实的用户，或者输入“*”，则所有用户都“可以”具有工作流管理员权限（用户实际是否有工作流管理权限还必须取决于其被赋予的“责任”或“菜单”功能），如下图48所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
实际具有工作流管理权限的用户在进入工作流管理“开发员工作室”TAB页后，可以查询出系统所有的“工作流类型”，可选择其一作具体设置，如下图49所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
上图中，工作流管理员选定具体需设置的工作流后，点击“运行”则可以打开该工作流的“属性”设置界面（具体有哪些属性可设置，不同工作流各不相同），如下图50所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
工作流管理员在工作流管理“状态监控程序”TAB页，可以监控选定工作流的具体运行情况的若干条目列表，针对每一个条目，可以查看其“活动历史记录、状态图、参与者回应、详细资料”等若干信息（必要时工作流管理员可实施干预，如更新属性、倒退、暂停、取消等等）。如下图51所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
系统在各应用模块基于业务处理功能，预置有若干不同工作流，有关详情容以后结合具体业务模块应用再来讨论。以下重点介绍一个比较特殊的工作流：在多个业务模块中均需使用且系统实施必须事先完善设置的“账户生成器流程”。
传统的手工业务模式下，所有可能涉及会计记账处理的业务处理例如物料接收、发出等等，作为业务处理人员在日常工作过程中是不需要考虑如何记账的，只是需要将有关业务处理记录例如入库单、出库单等作为原始凭证提交给会计人员去做处理。会计人员依据这些原始凭证制作“记账凭证”并手工为之指定“会计科目”或“账户代码”，以便正确地向总账GL实施“过账”。
手工业务模式或会计电算化模式下，由于作为原始凭证的业务单据不包含准确的记账信息（会计科目或账户代码），需要会计人员手工去做处理，这在业务量很大，记账科目数量设置较多的情况下，会计人员的工作负担将十分繁重。再考虑人工处理难免有疏漏，可能需要反复“对账”，每月月底必须及时结账关账、时间紧迫等等因素，故非人工的、高度准确的“会计分录（日记账）”自动生成功能（即所谓“自动会计”）是系统设计时必须考虑解决的重要问题。
在EBS系统中，账户代码被扩展为一个包含多个段组合的会计科目弹性域结构，系统在业务流程类表单例如采购订单、发票等做业务处理时，依赖所谓“账户生成器流程”根据业务处理的自身属性，自动生成准确的帐户代码组合并记录于业务表单的相关字段中，如下图52所示采购申请界面每个申请行（分配）所对应的“会计账户”（弹性域结构）：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
系统周期或人工启动向总账GL的“过账”流程，对符合条件的“事务处理”成批生成会计分录（日记账，是否还需复核审批视乎企业规定），一般来说无需再做繁琐的“对账”工作。这就大大减轻了会计人员的工作负担，记账科目数量的多少一般也不再成为障碍。（手工或电算化模式下，会计人员往往不愿意设置某些过渡性的“中间科目”，例如物料接收的“应计负债”等等，这对于会计工作的准确性有不小的影响）
ORACLE系统基于每个新定义的分类帐（帐套）自动生成所需的“账户生成器”，系统预置有14个账户生成器（工作流类型），对于每个“账户生成器”可以根据需要设置不同的“流程”（每个工作流类型有其LOV值，还可以使用Workflow Builder自定义添加），如下图53所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
“账户生成器流程”是基于“会计科目弹性域结构”来设置的，弹性域结构不同，流程设置可以不同。对于每个“账户生成器”，ORACLE都提供了默认的流程供使用。R11的账户生成器生成的账户代码被直接用之于向总账GL传送，而R12由于存在“多账簿”的不同“会计方法”因素，各子分类帐产品（业务模块）基于事务处理会计科目弹性域结构通过账户生成器而生成的帐户代码，在向总账GL传送时，还需结合“会计方法”中的“账户推导规则”等设置，才能在总账GL生成正确的会计分录（日记账）。
八、系统初始化设置
（一）关于安全性。
一个全新安装的EBSR12系统（Fresh Database），以SYSADMIN用户名登录，密码为sysadmin（注意EBS密码区分大小写），Home Page 可见系统所初始预置的10多个“责任”中包含“系统管理员”（System Administrator），如下图54所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
进入系统的GUI界面后，在“用户”定义界面，可查询到有30多个初始化的User，比较特殊与重要的User 是两个“SYSADMIN、GUEST”，GUEST无密码设置，可以作为测试时的特殊用户使用。如下图55所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
其中有些User是系统残留，并不可用，还有些是只有用户名，但并未为之分配责任。注意，上图初始的GUI界面默认配色方案，为演示方便已通过配置文件“Java color scheme”做调整。
系统初始预置的“责任”有1500多个，范围涉及所有模块的几乎所有“岗位角色”，企业可基于自身的管理习惯制定相应的责任“命名规则”，以定义新的“责任”。如下图56所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
系统初始预置的“菜单”有12000多个，基本上覆盖了几乎所有可能应用的需要，如企业需要“个性化”的菜单显示效果（prompt），则可以自定义用户菜单，形成特定的菜单结构。如下图57所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
本文为测试需要，在系统中建立用户名MFG，并将常用模块的超级用户责任均与之关联。为测试方便，建一包含所有常用超级用户菜单的总菜单，并以此建一超级总责任，也与用户MFG关联。
（二）关于配置文件
系统配置文件总数有6600多个，绝大多数有初始化的默认值，可以有需要时再来修改，有关系统配置文件的设置情况（初始化时尤其可能希望了解），可以使用工具栏“File—Export”将它们全部导出，以方便的格式如EXCEL集中查看，如下图58所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
有些必须设置且没有默认值的配置文件，例如“GL Ledger Name ”、“MO：Operating Unit”等，由于其LOV取决于系统的其它具体设置如分类账（帐套）、业务实体OU等，故这些特殊的配置文件初始进入时会报错，如下图59所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
这些少数的特殊配置文件是系统初始化参数配置是的重点与难点，在完成相关会计科目弹性域结构、分类账、组织架构等等设置后，应及时为这些特殊“配置文件”赋值。
（三）值集与弹性域
EBS系统初始预置有16000多个值集名（Value Set Name，包括近2000个“验证”类型为“无”、无需LOV的特殊值集名），基本上都属于系统各表单所使用LOV的值集，有着特定的用途，这些值集也可以根据需要修改添加新的条目行。如下图60所示。而对于系统键弹性域与说明性弹性域所使用到的值集，则需要根据企业具体情况，进行完善的定义设置（尤其是38个键弹性域所需使用的值集）。
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
关于键弹性域的设置，除了使用范围广泛的Item类别弹性域（Item Categories），系统已经预置有20个不同结构表示其在不同场合的多个应用之外（还可根据需要添加结构，系统预置的结构也可以进行更改，如下图61所示：）
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
其它键弹性域如“会计科目弹性域”基本只有一个结构名称范例，并无具体的结构设置，需要企业根据自己的情况来完成设置。所有的说明性弹性域均无预置结构，均需根据需要从值集开始设置。
弹性域结构的段也可以不选择值集而留空，则此时，此段就好象使用了这样一个值集：验证类型为“无”，格式类型为“字符”，宽度与基础键弹性域段列相同（即与弹性域系统设计所允许的段最大字符长度相同），允许混合大小写字母字符，无右对齐或填零。对于基础列不是“字符”列的任何段，则必须使用值集，否则将不能够编译弹性域。但需注意，“会计科目弹性域”必需使用值集。
已经定义并编译好的弹性域结构（键或说明性），在使用时均会打开弹出式窗口，以便逐段输入数据。但这样输入对于一些常用到的“代码组合”，既不方便记忆，也不方便输入，为此，ORACLE为定义的每一弹性域结构的代码组合提供了“别名”（Aliases）定义的功能。例如，实际工作使用得比较多的“账户代码”的“账户别名”就是一个典型。其它弹性域结构是否需要使用“别名”，取决于实际业务需要。
（四）分类账（帐套）与组织架构
这是系统初始化设置最复杂的工作。R12较之R11，由于引入了“会计方法”的新维度，在设置方法与顺序方面有较大的变化，其过程也更为复杂。R12的法人实体LE的设置与R11相比也有很大变化，只能在“会计科目管理器”中设置，原在GUI组织设置界面的LE设置的值不再有效（即使设定也无法分配给分类账）。有关多组织、多账簿的接入功能还需与“安全性配置文件（Security Profile）、数据访问权限集（Data Access Set）”的定义，配置文件“BG：安全配置文件、MO：安全配置文件、GL：数据访问权限集”等等参数的设置进行协调配合，包括运行“转换为多组织体系结构（仅R11，在AD Utility 工具中执行；R12安装已经是多组织结构）”以及为新添OU“复制系统初始数据”（在“系统管理员”责任下，运行“Replicate Seed Data”请求）公用程序等等。有关详情，限于篇幅，这里不再赘述。
（五）单据编号
新安装的EBS系统初始并未定义单据编号发生器，需要全新定义，如下图62所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
需要指出的是，这里的“单据编号”仅是“系统内部”使用的标识，都是不包含任何业务管理信息的数字代码。某些特殊单据如采购申请、采购订单以及供应商等虽具有自己专门的编号管理机制，其所生成的也是不包含业务信息的数字代码。这些数字代码和实际业务管理中所需使用到的“业务标识”可能有一定区别，例如对于采购订单、供应商，基于管理的某些特殊需要，除了系统自动生成（或手工输入）的单据代码标识外，可能还需使用单据头的“说明性弹性域”生成包含“采购员代码、业务类别代码、行业代码、地域代码”等等管理信息的“业务标识”（可能需要打印在纸面单据上），以方便相关业务信息的统计分析工作。
系统初始预置有若干数量的“单据类别（Document Categories）”（属于GL/AP/AR），每个单据类别对应数据库中的某个表（Table）。可以根据需要为相关业务模块如INV/PO/OM等等的某些表（Table，是否允许取决于Table本身的设计）添加“单据类别”，以便对表中的相关字段应用编号机制。未来在完成系统设置过程中，还会基于某些表单的业务类别设置（例如销售订单类别等）自动生成新的单据类别。如下图63所示：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
单据类别与单据编号发生器的关联分配是基于分类账（帐套）的，故在每次新定义分类账或帐套后，均需完成有关的单据编号“分配”工作。
（六）层次性设置结构
不涉及具体应用模块或具全局性、属于EBS系统层面的初始化设置，还包括工作流、预警、文件夹、配置文件定义、查找代码定义、消息定义、地区维护、打印机等等一系列内容，限于篇幅，这里不再赘述。下图64所示表达了EBS（R11）全系统公共层面的基础设置内容与层次结构： Common Applications Process Hierarchy
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
EBS核心系统习惯上可以划分为四大分支系统：财务、制造、分销、人力资源。每一大分支系统也有相关的公用层面设置，如下图65所示是EBS（R11）公共“分销系统”的基础设置内容与层次结构（公共财务、制造、人力资源的相关层次结构比较简单，故略）：
Common Distribution Process Hierarchy
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
而涉及具体应用模块的系统初始设置，情况就更为复杂，通常需要按照应用模块的设置流程图，结合全系统与分支系统的设置情况来决定具体如何执行。如下图66所示是EBS（R11）采购系统的设置步骤：
系列之四：ORACLE EBS基础设置要点简介（E） - season - season
对应上述设置步骤的是下述列表清单。流程图和设置步骤清单概括了各设置步骤，其中一些步骤是必需的，而另外一些步骤则是可选的。“具有默认值的必需步骤”是指在数据库中预植了默认值的设置功能。但是，通常需要复查一下这些默认值，以决定是否要对其进行更改。其中有些步骤在“系统”或“分支系统”层如果已经设置，则在应用模块层就无需再执行这些设置步骤。
步骤
必需
步骤
AIW 参考
1
必需
设置系统管理员
Common Applications
2
必需
定义会计键弹性域
Common Applications
3
必需
设置日历、币种和帐套
Common Applications
4
必需
定义人力资源键弹性域
Common Applications
5
必需
定义地点
Common Applications
6
必需
定义组织和组织关系
Common Applications
7
可选
转换为多组织体系结构
Common Applications
8
必需
定义库存键弹性域
Common Applications
9
必需
定义单位
Common Applications
10
可选
定义承运人
Common Applications
11
具有默认值的必需步骤
定义物料属性、代码和模板
Common Applications
12
必需
定义类别
Common Applications
13
可选
定义目录组
Common Applications
14
必需
设置人事
Common Applications
15
必需
设置 Oracle Workflow
Common Applications
16
必需
决定如何使用帐户生成器
Oracle Purchasing
17
必需
打开库存和采购会计期
Common Distribution
18
可选
定义子库存地点
Common Distribution
19
可选
定义交叉引用类型
Oracle Purchasing
20
可选
定义税码
Common Financial
21
可选
定义付款条件
Common Financial
22
必需
设置审批信息
Oracle Purchasing
23
具有默认值的必需步骤
定义查找和分类
Oracle Purchasing
24
可选
定义标准附件
Oracle Purchasing
25
必需
定义采购选项
Oracle Purchasing
26
必需
定义采购员
Oracle Purchasing
27
可选
定义物料
Oracle Purchasing
28
具有默认值的必需步骤
定义行类型
Oracle Purchasing
29
必需
启动采购数据库管理程序
Oracle Purchasing
30
必需
定义财务选项
Common Financial
31
可选
定义事务处理原因
Oracle Purchasing
32
必需
定义接收选项
Oracle Purchasing
33
必需
设置事务处理管理器和重新提交时间间隔
Oracle Purchasing
34
必需
定义供应商
Common Financial
35
具有默认值的必需步骤
设置工作流选项
Oracle Purchasing
36
必需
提交工作流相关流程
Oracle Purchasing
37
可选
定义说明性弹性域
Common Applications
38
可选
设置自动来源补充
Oracle Purchasing
39
必需
执行附加的系统管理员设置
Common Applications
40
必需
定义制造系统和用户配置文件
Oracle Purchasing
如果要实施多个 Oracle Applications 模块产品，ORACLE建议使用 Oracle Applications 实施向导 (AIW，Oracle Applications Implementation Wizard User's Guide) 来协调设置活动。该“向导”将指导用户完成对已安装应用产品的设置步骤，给出满足交叉产品相关性要求的逻辑实施顺序并免去多余的设置步骤。用户可以使用“向导”来查看以图形表示的设置步骤概览、查阅设置活动的联机帮助和打开相应的设置窗口。通过使用“向导”来为每个步骤记录备注信息，还可以记录实施情况以供日后参考和复查。
根据系统功能，一些厂商的OA系统可设置转发，比如金和软件就具备这个功能。 崛创科技成就卓越IT能力
在“文件”菜单上指向“新建”，然后选择“项目”。此时将打开“新建项目”对话框。在“项目类型”窗格中，选择“Visual C#”或“Visual Basic”（位于“其他语言”下），然后选择“工作流”。在“模板”窗格中，选择“工作流 Activity 库”。
本报告对SAP和ORACLE两家公司的ERP产品，从公司实力、软件功能、产品成熟度、产品技术和产品实施等几个纬度进行比较，以使企业能够更好的了解哪个产品更适合自己。
1:软件产品的成熟度
§ SAP：经过近30年与全球大企业用户的合作，SAP系统积累了大量先进企业的业务管理流程。对于用户来说，只需根据在系统中挑选适当的业务流程，在软件中进行配置。而对软件的二次开发工作量极少，这就保证了用户能够把主要的精力都花在企业业务流程的优化上，真正起到上一套系统，管理提高一个层次的作用。
§ Oracle: 由于缺乏足够的业务流程模板和软件功能的支持，在实施中Oracle软件经常被发现无法满足企业管理上的要求。比如在大型制药企业中必须的批次管理、质量管理、设备维护管理等，而Oracle软件根本没有此类模块。虽然Oracle公司一再的夸大告诉客户其软件的二次开发技术十分灵活，但是这实际上也就是在告诉用户这套软件功能不够，用户得自己去编程序。
§ SAP：秉承德国企业严谨的文化，所有发布的产品都是经过严格的测试和质量认证，只有在软件产品真正完备后才向用户推出。
§ Oracle公司是一个非常注重市场效应的企业，经常是一有概念就马上宣称产品完成，然后快速推向市场。但是，软件产品得漏洞和缺陷给其用户得实施和使用造成了巨大的痛苦。2002年1到3月，Oracle发给新产品用户的修补程序包竟然高达5000个以上，这对用户来说无疑是一场恶梦。
§ SAP：作为ERP系统的重要组成部分，SAP花了2年的时间进行汉化和按照中国政府的人事管理要求进行本地化，使得SAP的中国用户不仅能够使用国际化的先进软件，同时也满足本地化的要求。
§ Oracle：对ERP软件产品本地化重视不足，至今在中国地区，Oracle的用户还没有一家能够使用Oracle软件的人力资源管理模块。
不同的产品质量和市场策略，造就了不同的用户群体
SAP在中国
公司经营理念的不同，最终一定会反映在其用户群体的实施效果上。以中国为例，SAP的用户群体中，大型企业实施成功的比比皆是，这些企业纷纷把自己的成功经验向社会传播，报章媒体上宣传实施SAP实施成功的文章时时可见，比如：
2001到2002年中，又有中国最大的矿业集团-兖矿集团，列入全球财富500强的-中国石油化工集团，国内四大通讯设备厂商之一-大唐电信集团，中国最具活力的报业集团-广州日报集团等大型、浦东发展银行超大型企业纷纷加入SAP的用户群体。
Oracle在中国
与SAP的广泛成功形成鲜明对比的是，Oracle依靠低价格来得到的客户，实施效果却良莠不齐，鲜见有在媒体上宣布自己实施ERP成功的;特别是在大型企业集团的实施上，鲜见其有成功客户。特别是在一些大型项目上，其急功近利的市场策略造成的恶果已经开始显现。
§ 中国移动通信：在广东、江苏、浙江的试点实施Oracle系统，软件的先天不足和实施力量的经验缺乏造成实施瘫痪。2001年7月，中国移动痛下决心，对尚未实施Oracle的其他13个省的ERP项目重新进行招标，而邀标书就发给了SAP 。而作为中国移动的母公司，中国电信，吸取前者的教训，谨慎的进行评估和实施。在北京电信公司和上海电信公司已经开始实施SAP。
§ 上海宝钢：产品无法适应大型企业复杂的管理需求，实施半途而废，现在宝钢已经完全放弃了系统的使用。
§ 中国民航：实施力量薄弱，在试点实施效果不理想的情况下，中国民航进退维谷，既没有信心向全国推广，也没办法放弃。
§ 实达电脑：Oracle在中国最大的实施合作伙伴-汉普公司，其实施能力让实达公司的领导层忍无可忍，只好中途将汉普的咨询队伍"请"出了实达公司。Oracle公司只好换上其他合作伙伴，但实施何时能够完成，还无法预料。
§ 江苏沙钢集团：从1997年开始实施Oracle ERP，经历了漫长的实施过程和庞大的二次开发工作后，终于在2002年5月放弃了Oracle软件，转向SAP。
以上这些案例足以说明，Oracle的两大致命弱点：软件功能不足、实施力量薄弱决定了，其方案在大型集团化企业的项目上的成功十分困难。这些先天的障碍，给这些大型集团化企业的信息化甚至是企业经营造成了巨大的隐痛。
2、 技术的先进性
Oracle 应用系统11i 版本是真正完全基于互联网INTERNET架构，并且采用开放的JAVA语言和技术标准进行编写的应用软件，这种技术的开放性，使Oracle 应用系统11i版本有越来越强的生命力(开放的标准意味着应用系统软件不受硬件平台, 不受企业规模大小, 不受地域限制等因数的影响)，而SAP软件的主体部分还是完全用其私有的ABAP语言编写的，学习和使用都很困难且与INTERNET或网络应用WEB技术不兼容(JAVA目前已经成为全球INTERNET应用系统的应用开发标准，而懂ABAP语言的开发人员非常少)，虽然SAP也在试图转向JAVA标准，但由于其目前的系统过于复杂和庞大，完全的转型几乎不可能。 非INTERNET结构上的应用系统, 基本是基于客户/服务器(C/S)的结构,这在现在的INTERNET时代,是已经过时或被淘汰的技术,它将限制应用系统的规模和并发用户数,也不可能用于全球一体化的管理系统 - 即跨国或跨地区的大型企业将不可能应用一个数据库的管理系统, 这将给这些选用该C/S 系统的企业带来巨大的系统投资费用和系统维护成本, 也使企业不可能在今后发展时,继续使用已投入的信息系统, 即在原系统上增加新功能/系统的逐步实现企业信息化的设想成为不可能。
虽然从表面上看，最终用户似乎感觉不到软件技术架构带来的变化，但事实上，是否选择符合发展潮流的技术方向会极大地影响到软件厂商及其应用客户的生命力。历史上，由于没能选择符合潮流的技术而迅速衰落的大软件厂商比比皆是(曾经在ERP领域领导潮流的SSA， 由于不能将系统及时转向开放的UNIX平台，而迅速衰落)而这同时也给选择这些厂商产品的客户带来了极大的风险。
ORACLE应用系统充分采用了数据库上的先进技术，将有些系统功能放到数据库中去实现，而不是通过编程的方式，因而大大简化了程序，提高了效率。而SAP系统为支持多种数据库，不可能采用数据库技术去实现数据库端的功能，只是将数据库用来储存数据，其原因有两方面，一是SAP公司不是数据库技术公司, 不专注于数据库技术，二是SAP也不愿意将自己的产品捆绑在一种数据库上，但这种做法牺牲了客户的利益。
ORACLE系统具有强大的查询功能，在其输入数据的界面中，输入的任何数据都可做为其查询条件。SAP则需要专门定义查询界面。
ORACLE 电子商务套件已经脱离了传统的ERP软件模式，提供了集成的商业智能、个性化管理界面、工作流和告警等全新的功能。传统的ERP软件，用户需要进入层层菜单，运行查询或报表，才能得到业务数据。而使用ORACLE，用户可以在个性化的企业门户网页中，自由定义所需的智能报表，就能迅速了解企业、相关业务的执行情况。系统还能够对非正常业务自动告警。ORACLE 系统以人为本，帮助企业的管理人员充分利用ERP的业务数据，更高效地管理企业。
3、 创新性、生命力、在新兴应用领域的发展
由于ORACLE相对于 SAP 先天的技术优越性，使ORACLE能够根据各行业的发展变化趋势，迅速将产品拓展到各种新的应用领域。例如，ORACLE在客户关系管理、电子商务、产品协同开发等各行业的新兴领域都要领先于SAP，显示出ORACLE卓越的创新能力和越来越强的生命力。而SAP由于本身体系的复杂性和技术的封闭性，使得其在各种新的应用产品领域进展缓慢，例如，SAP虽然已经拥有庞大的制造业客户群，但在客户关系管理领域一直碌碌无为，在B2B电子商务方面也不得不依靠与Commerce One的合作，直到2001年才解除与Commerce One 的合作，推出自己的产品。
4、 业务数据的共享和分析
随着企业应用管理领域的不断扩展，企业应用系统涉及的范围也越来越广泛，从传统的制造、财务、人力资源系统管理，开始延展到客户关系管理、供应链管理、电子商务等方向，在这种情况下，系统之间数据的一致性和数据交换，就变得非常重要。ORACLE 11i 整个系统基于一个统一的数据库，并且共享统一的数据模型。企业内所有的用户都可以根据自己的角色和权限对系统中的数据进行不同维度的分析。而SAP的ERP、供应链、客户关系管理、数据挖掘等应用系统分别构建在不同的数据库上，不同系统间的数据模型也不相同，这使得各系统之间的数据共享变得非常困难或者不可能。
5、 软件功能的比较
SAP体现了德国人的管理风格：求严求全;ORACLE体现了美国人的管理风格：求实求用。
SAP
SAP 功能复杂、全面，特别在传统的ERP功能方面，系统功能设计比较细致。SAP通过复杂的参数表、层层定义来实现各中功能。系统可以通过6000 个"开关"设置，调整软件的业务流程。SAP参数设置是非常复杂的，例如，对采购定单下达过程的管理，SAP需要预先定义：先定义定单特征码，再定义相应的特征(如金额大于100圆)、分类、下达组(Release group)、下达编码(Release codes)、下达标志(Release indicator)、下达策略(Release strategy)，工作流标志等，再通过一系列规则表值的设置，才能实现采购定单批准下达的过程。如果需要修改下达过程，则必须从定单特征码开始修改。
SAP的参数设置实际上包括了软件的底层数据结构，功能较强，但实施非常复杂，不够灵活。如果企业的业务需要调整，就会涉及非常多的底层数据设置，参数和规则的调整，甚至可能影响已有业务数据。
SAP在CRM(客户关系管理)和E-Business(电子商务)方面已远落后于ORACLE。
ORACLE
ORACLE 软件的业务流程控制结构非常灵活，并充分利用工作流的功能来控制软件的业务流程。因此，可以灵活地调整软件的业务流程。例如，同样对采购定单的下达过程，ORACLE 利用采购定单的数据(不须设置特征参数)，通过工作流引擎，自动检查采购定单的数据，如金额、采购员、供应商等，根据条件判断，实现不同的采购定单批准下达的过程。如果需要更改业务流程，无须更改特征参数，只需更改判断规则或控制规则。
ORACLE 的控制参数设置不须修改数据结构，而是通过采用不同的控制参数来调整程序的逻辑。这是因为ORACLE 采用公共的数据模型，程序中充分利用现有的业务数据，通过灵活的规则设置来实现灵活的业务流程。
ORACLE 在新的业务功能占据优势。如混流生产、CRM、电子商务协作等，都是根据最新的业务模式和知名客户的实际业务流程开发的。
结论
由于企业的多样性和复杂性，任何ERP软件都不可能覆盖企业的方方面面。ORACLE较能适应企业的业务的个性化，便于调整;而SAP较适应稳定、标准的业务流程，难以改变。这也是SAP强调SAP代表了先进业务流程，要求企业适应软件的原因。
6. 软件的开放性和集成性
SAP
SAP的软件各模块在搭建上采用的是传统应用软件的模式，即在程序中用包含头函数以及子程序等模式。这种模式在与第三方软件交换数据时，只能通过编写接口程序来实现。SAP软件的应用层是使用ABAP语言编写的程序，ABAP是比较复杂和只有SAP软件使用的语言，比较难掌握，又由于其只能在SAP的软件中才能发挥用途，掌握的人也很少. IT专业人员学习它的积极性也不高. SAP系统在与外界交换数据时, 其接口程序也要求用ABAP语言来编写，具体是用ABAP语言中的函数来向系统中导入数据，其对数据的格式要求也很高，要求的数据必须是带分格符的文本文件。SAP的这些做法导致其软件系统在同第三方软件集成上远远落后于ORACLE，同时这些做法也阻碍了其自生软件的进一步发展，这也是SAP的ERP与CRM不能完全集成的原因之一。
ORACLE
ORACLE公司凭借其在数据库方面全球领先的优势，其应用软件在模块的体系搭建上采用了一种先进的模式，各模块之间以及与外界交换数据都必须通过接口表来完成，具体的做法是数据要进入各模块时，都必须先到各模块自己的接口表中(每个模块都有自己的接口表)，然后再通过并发等方式导入该模块中，这种模式很容易将第三方的软件融入ORACLE的系统中，用户在使用时很方便，感觉象是一套软件，因为在交换数据时第三方的软件与ORACLE的产品各模块间交换数据的模式是一致的，同时用户可以以自己熟悉的数据库语言(VB，PL/SQL等)来编写应用程序与ORACLE系统集成。
ORACLE凭借其软件系统在体系上的优势，将其ERP、CRM，SCM，EB等系统完全集成为一体，形成今天的电子商务套件。
结论
任何ERP软件都不可能覆盖企业的多样性和复杂性的所有方面，对于企业的特殊要求用户自己可进行必要的二次开发，并可以同其他应用软件方便地集成，这就要求供应商提供的软件具有很强的开放性。ORACLE 开放、灵活的体系结构更利于企业信息系统未来的扩展。
7. 软件的实施复杂性及投资回报
SAP项目实施过程十分昂贵和复杂。 而且，由于其软件的复杂性和封闭式集成，一旦实施后很难改变。 另外，SAP在项目实施过程中，经常会期望客户改变商业运做模式以适应其软件， 但有时候，一味迁就软件流程的做法很可能会给客户带来负面结果。一些超大型企业可以投入巨资进行软件的客户化，但是对于中等规模的企业，复杂的项目实施，往往会将客户拖入无休止的泥潭。国内一汽大众的SAP ERP的累计实施投资已经过亿圆，但实施效果其实并不理想。之后一汽又选用了与SAP的ERP "配套" 的CRM供应商SIEBEL软件, 其CRM系统实施了几年, 至今没有上线。 而Oracle 的应用产品具有很强的灵活性，许多业务的流程可以通过工作流技术很方便地进行改变，同时Oracle 系统本身的开放性也使Oracle 系统与其它系统的集成变得相对简单。
实施问题：
1、我的企业管理流程与你们软件有差异，怎么办?
2、听说ERP实施难度很大，成功率低，你们怎么看?
SAP
SAP对所有行业都有完备的解决方案，我们的专家将协助你选择最佳模式;如果你现有的业务流程与SAP系统有差异，建议调整你的业务流程。
首先，这个说法并不十分确切，SAP在著名的跨国公司的成功就说明了问题;其次，很关键的问题在于客户，尤其是许多中国客户对企业信息化的理解不足，基础管理水平较低;
SAP系统对顾问和用户的要求都很高，特别是在SAP系统中，很多功能需要先在后台设置参数，再通过编写专门的ABAP语言程序来实现。这种情况下往往要求顾问和用户既懂应用，又具有一定开发方面的知识，因为ABAP开发人员一般是不懂后台应用系统设置的，而应用实施顾问往往又不知道这种与开发相关的系统设置，这种情况就是在SAP自己的实施队伍中都会碰到。
SAP过于复杂，很多不适合中国企业的功能混在一起，有6-7千个参数需进行设置，用户非常难以掌握。投入大量资金也很难培养出来合适的技术人员。 然而, 即使培养了一些技术人员, 一旦跳槽，则系统就会面临瘫痪。
ORACLE
首先，系统灵活和开放, 有几乎所有流程/模块的系统界面, 基于丰富的行业经验基础上开发的优秀业务模型和标准流程和功能可满足客户的需求, 也可供客户借鉴;其次，如果客户不满意已有的流程和功能，IT 行业使用最广泛的ORACLE开发工具将可方便地使用户按其要求进行客户化开发来满足企业的需求。
首先，这是事实;其次，实施是软件商和客户共同的事业，必须选择适当的策略，给予充分的支持才有可能成功。
ORACLE系统提供了清晰的业务流程，可以帮助企业在实施的同时理顺业务流程。ORACLE 的业务流程可以根据企业的实际情况灵活调整，更适应企业的个性化管理。
ORACLE数据结构清晰、严谨，开发工具使用的是世界 IT 行业最普遍使用的语言, 如: JAVA 这唯一真正INTERNET计算机语言，易于开发, 且开发的系统才是真正的INTERNET上的应用系统。
结论
ORACEL 更适用于业务复杂、个性化管理的企业。ORACLE软件实施的难度和复杂性，实施成本，风险远低于SAP。由于其系统的特性，SAP的实施成本、实施周期远大于ORACLE。
个人是推荐使用SAP ERP ，SAP是ERP比较多人使用的软件，是德国公司开发的，ORACLE是甲骨文开发的，没有sap这么成熟和完善。
SAP ERP体现了德国人的管理风格：求严求全。 SAP ERP功能复杂、全面，特别在传统的ERP功能方面，系统功能设计比较细致。SAP ERP通过复杂的参数表、层层定义来实现各中功能。系统可以通过6000个“开关”设置，调整软件的业务流程。
Oracle ERP(甲骨文 ERP)的业务流程控制结构非常灵活。它充分利用工作流的功能来控制软件的业务流程，可以灵活地调整软件的业务流程。Oracle的控制参数设置不须修改数据结构，而是通过采用不同的控制参数来调整程序的逻辑。这是因为Oracle采用公共的数据模型，程序中充分利用现有的业务数据，通过灵活的规则设置来实现灵活的业务流程。