一个问题的征兆

鳄梨比喻
从开发人员的眼光来看,ERP 软件包的结构就像一个成熟的鳄梨,在一个硬质核心外面有

一层软质包裹

.鳄梨的软质果肉就像围绕着 ERP 的界面.交互式图形用户界面包括本机代码

和提供网页的

Web 服务,以及用于通过电子数据交换(EDI)和其他企业应用集成(EAI)

机制

连接同类系统的非交互式用户界面

.想连接另一个系统或者拥有新的视觉外观?

只需修改界

——

面就可以办到

这些界面是相当具有延展性的

.相比之下,ERP

系统的硬质核心是实现业

务逻辑的软件

,定义每个业务流程与流动规则以及用于确保数据准确性,

完整性和适当性的规

则与惯例的大量集合

.业务规则对公司数据库"堡垒"进行保护,

阻止来自外界的不合逻辑的数

据破坏公司的信息本身及其价值

.业务规则是 ERP 系统的核心,

比数据库设计更宝贵

,因为它

们更难创建和维护

业务规则及其在其中得以实现的框架不是随便可以改动的

. 为更好地理

解作为

ERP 系统的皇冠宝石的业务规则,

请考虑一个看似简单的库存提货事务的例子

. 我们

假设一定数量的某一特定库存项目被提走

.这时会发生什么?当然,

ERP 系统会减少现有库存量. 另一条业务规则会指示在库存事务历史记录表中增加一条

该事务的记录

. 还有其他业务规则执行总账的借方和贷方过账. 如果刚发生的提货事务是一

个预先计划的事件

, 则可能还会写下一条记录以减少或取消对提取库存的等待. 另外还有业

务规则处理任何批次跟踪或序号分支

. 如果提货是作为针对客户订单的发货而发生的, 则有

许多其他业务规则发挥作用

.这些规则会写下一条发货日志,减少销售单上的"等待发货"

(remaining to ship)数量,触发发票系统和应收账款,发送一条信息以提醒客户,

更新对该客

户的发货的销售历史记录

,计算售出货物的价款,写下针对销售人员的佣金等的记录.

向哪个

总账科目过账

?价款如何计算?什么销售人员获得佣金?是否缴了什么税?

涉及的批号是什么

业务规则涉及所有这些问题以及更多问题

, 因此, 在本例中, 当提货事件发生时,

构成

ERP

系统的所有相关子系统和表都得到正确的通知

,数据准确性和完整性也得以保持. 这些业务规

则是现代

ERP 软件系统的核心,是客户期待 ERP 系统提供的价值的源泉.ERP 系统的大多数

开发和测试工作都花在确保这些业务规则的正确性

, 完整性,

被正确调用以及所有事务的顺

利而高效的执行

.除了最表面的软件功能以外,ERP

系统中的所有功能都是以业务规则的形

式实现的

.如果说数据库是 ERP 系统的心脏,那么业务规则就是 ERP

系统的灵魂

一些需要隐藏起来的东西
在今天的许多 ERP 软件包中,

——

真正的工作仍然是由一个老旧和过时的软件主体

很久

——

以前用旧软件语言编写的业务规则

而完成的

.这些旧"宝石"一直被珍藏,夹在较新的软件

层之间

,与几十年的技术变化相隔绝.通过在其下面插入一层新代码,

诞生于已废弃操作系统

之上的旧软件还是可以运行于现代

Windows 操作系统之上.而且,

通过以现代图形用户界

面和

EDI 代码层进行包裹,它可以与外界相隔绝. 因此, 在上世纪 70 年代和 80 年代期间开

发的软件还居于许多公司系统的中心

这些软件的设计者当然不知道我们目前拥有的微软

.NET, XML, GHz 处理器和其他所有技术与标准. 2.3 他们熟知的是过程式语言,8 MB 内存,
1200 Kbps 调制解调器,

简易终端设备以及计算机机房的活动架空地板

.但无论是当时还是

现在

,在业务规则方面的投资都是巨大的,

而且这些老代码看起来依然有用

.所以,在谈到 ERP

系统的中央核心时

,"如果它没有破裂,

就不要修补它

"一直是大家奉行的原则.或者也可以这

样说

:"不要更新它,

把它包裹起来就行了

具有讽刺意味的是,对拥有旧业务逻辑代码的一些公司来说,转而对用户界面使用互联网浏
览器实乃天之所赐

从营销角度说您有一个

Web 浏览器界面听起来相当"先进".

而承认是

用

"屏幕抓取器"(screen scraper)包裹了旧代码则没有这种效果.但从技术上讲,

效果是相

同的

,都不过是给旧软件的核心改头换面而已. 后来,

在

.NET 技术出现后,

以新的

.NET 等同

物来更换其包裹软件和打出

.NET

旗号对

ERP 公司来说相对容易一些.XML Web 服务的情