第三方物流3PL/SCM系统设计技术

系统设计是系统开发的关键阶段，该阶段从技术上和功能上定义了系统的实施和开发框架。这里我将从系统设计的角度，考察 3PL 功能模型，技术路线和数据库设计三大部分。至于商业模型分析和应用设计将在以后有空的时候再撰写。

§1-1 功能模型

§1-1-1 功能模型设计目标

根据供应链物流管理的要求，功能模型的设计应瞄准如下目标：

l          提高供应链物流企业管理水平，改善决策支持灵敏度，完成企业数字化提升

在供应链一体化运作和管理中，实现信息化是最基本也是最重要的管理目标。在供应链周期中，端到端的交易执行从最初供应商订单到最终送达客户和客户支付过程中物品、信息和资金的无缝流动，是供应链管理的最重要原则，实现这一目标的基本手段就是供应链管理信息化系统。

l          实现物流、信息流和资金流的高度协调与无阻塞流转

一个运行稳健的供应链物流管理系统应该是物流、信息流和资金流的高度协调和统一，任何一种“流”出现断点不仅会使得交易和管理搁浅，而且会对企业的运作过程导致不可预料的灾难。

l          发现并且保持供应链关系，从而增加商业机会，开拓新的市场

在目前竞争日益激烈的知识经济环境下，销售商关系、客户关系等供应链关系管理对增强并维持供应链关系至关重要。越来越多的企业将接受网络化的业务，电子商务技术将是未来商业活动的标准模式。供应链物流信息化管理平台通过与 Internet 的无缝集成，为企业提供了无国界、无时限的理想的和低成本的信息发布渠道，商业机会因此大大增加。

l          改善业务受理质量，提高销售、采购、物流加工、库存管理的柔性与敏捷度

对 于业务受理过程的跟踪和分析，可以从统计分析的角度挖掘减少失误、节约交易处理时间、降低对人力资源占用的优化手段。我的供应链数据分析系统将贯穿于供应 链管理的各个阶段，动态分析和实时洞察企业的采购、销售、和配送规律以及与其他贸易合作伙伴的关系，真正建立高效的物流配送系统。

l          功能模型的可配置特性

供应链物流企业面对的是瞬息万变的市场，企业家们不得不随时调整和更改先有的商业模型和业务流程运作方式。因而，供应链物流企业的功能模型应该具备良好的可伸缩性，以满足为适应市场而不断调整的商业运作模式。

§1-1-2 功能模型分析

商业模型是基础，功能模型是商业模型的应用体现。

在 设计功能模型的过程中，我依然采用层次结构的方法来观察和分析应用系统的功能结构。这里的功能模型仅仅从结构上对未来应用系统的功能结构作了分类与描述， 其中每一个子系统涉及到繁多的具体业务操作过程和功能模块，等我有时间的时候，会在应用设计中会有详细描述，这里不做赘述。

 

  图 1-1     功能模型的层次结构

考察图 1-1 ，系统的功能模型由 5 个逻辑层次构成，分别是：

l          数据库层

l          系统管理与配置层

l          核心业务驱动层

l          核心业务层

l          商业智能层

 

（ 1 ）数据库层

无论是物流、信息流还是资金流，在应用系统的运作过程中，本质上都体现为数据的流动。从系统设计的角度看，数据库层位于应用系统的最低层，是一切系统操作与应用功能的基础。

数据库层的设计必须满足如下原则，具体的数据库设计模型将在本章 --- 数据库系统模型中描述。

l          数据的层次性、一致性与安全性                         

数据的流动过程是数据形式的变化与处理过程，在数据库中体现为数据的层次性：由具体的凌乱的数据到规范的格式化数据和经过处理的数据结果等，无不体现为层次性；此外，数据的一致性与安全性是所有数据库系统必须提供的管理目标。

 

图 1-2     数据库角色的转变

l          数据的存储与管理者，而非业务逻辑的处理             

传统意义上数据库管理系统经常把数据的管理与业务的处理都交给数据库系统自身完成。但是，随着应用规模的扩大与软件技术的发展，这种管理方式的弊端日益显露：不具备良好的伸缩性、可移植性与可维护性，系统效率到了某个阀值 (threshold) 也会因此而显著下降。

因此，随着中间件（ middleware ）的出现，数据库的角色转变为数据的存储与管理，业务逻辑的处理则交给中间件完成。如图 1-2 所示。

（ 2 ）系统管理与配置层

系统管理与配置层是系统运行的基础。该层基于数据库，对上层提供基础的系统管理配置功能和运行保障。

该层包括四个大的部分：系统管理、应用配置管理、商业基础资料管理、商业规则管理。

无论从系统应用的角度还是从商业运作的角度，上述四个部分都是系统运行的最基本要素。

（ 3 ）核心业务驱动层

从商业运作的角度看，有了数据和基础的商业资料的管理，似乎可以着手核心业务的运作了。

但是，作为一个统一的、协调的整体，我知道供应链物流企业的核心业务无一不是在业务规则的指导下，沿着一定的业务路线运作的。因此，所有的业务运作都有其特殊的规律，这些规律体现为一定的业务流程。

因此，在进行核心业务的运作之前，必须考虑一个统一的、稳健的业务流程驱动方式，使得所有的核心业务均在这种方式的有效驱动下，平滑流畅的运作。这就是工作流引擎。

工作流引擎

工作流引擎是我这个系统的重要特色和核心技术。所有核心业务的操作均在工作流引擎的驱动和控制下运行，因此，我将专门对工作流引擎的数学模型作分析。

EAI 引擎

除了工作流引擎之外，在本层我还考虑了两个重要的基于 web service 技术的引擎： EAI 引擎和应用门户协同引擎。

EAI 引擎用于与企业的其他信息平台相互集成，如 ERP 、 CRM 、财务管理等。

应用门户协同引擎

通常，一个规模较大的物流服务公司会有多个分公司遍布世界各地，这些分公司之间会有频繁的信息交换和统一的业务管理手段。本系统将提供两种架构来满足这一需求：独立系统运作和多系统协同，如图 1-3 所示。

 

 

图 1-3     独立系统和多系统协同

独立系统运作的方式是所有的分公司共享一个信息平台，采用互联网技术进行信息交换。但是，这样的系统对于企业的网络环境和基础架构要求很高。

多系统协同的方式是每个分公司采用独立的系统平台，但是系统平台之间采用应用门户协同引擎来协调运作。这种方式对基础架构与网络环境的要求不高，但是难以保障总公司对各个分公司的实时性管理。

至于供应链中成员企业之间的信息交互则通过远程访问与信息发布子系统完成。

（ 4 ）核心业务层

核心业务是提升企业价值和核心竞争力的主要源泉。在工作流引擎的驱动之下，企业核心业务的运作可以划分为十个子系统。下面十个子系统的具体功能模块将在以后有时间的时候再作描述，油画先生我太忙了。

l      库存管理子系统              库存管理系统是核心业务管理层的基础，其他子系统的运作过程都与库存状态相关。库存管理子系统包括服务商或分销商库存管理和供应商库存管理。

l      订单管理子系统              订单管理子系统主要管理各种订单的生成、订单的导入、订单的预处理。

l      销售管理子系统              经过订单管理子系统对销售订单的预处理之后，开始履行销售订单的过程管理。

l      采购管理子系统              采购管理子系统虽然本身是一个独立的管理系统，但是与销售管理系统密切相关，因为销售需求产生采购需求。

l      物流配送子系统              销售管理子系统开出发货单之后，开始履行全程物流配送，包括装载、运输、报关等。

l      物流加工子系统              流通过程的加工是物流服务商的增值业务。由销售业务引发物流加工。

l      逆向物流子系统              逆向物流是供应链物流管理的一个重要方面。包括：退货、维修与翻新、废弃等。

l      计划与控制子系统          根据销售需求生成采购计划；根据客户的采购需求生成销售计划和生产计划；根据配送需求生成装载与运输计划等。

l      业务跟踪子系统              对 业务受理过程的全线跟踪，是企业管理者必须掌握的运作状态。业务跟踪包括业务过程跟踪和业务时限跟踪两种方式，业务过程跟踪应该能够跟踪到每一笔业务的每 一个细节，包括：销售业务跟踪、采购业务跟踪、库存状态跟踪、运输状态跟踪等。业务时限跟踪则可以跟踪每一笔业务在每一个业务受理者或部门的停留时间与受 理时间。

l      远程访问与信息发布      远程访问与信息发布子系统包括如下几个部分：通过互联网的跨越时空的远程业务受理；电子数据交换；客户订单的上载与信息反馈；业务受理状态的发布。

（ 5 ）商业智能层

商业智能层包括：数据查询、数据分析、智能报表与决策支持。如图 1 - 4 所示，可以划分为如下五个逻辑层次：

l          数据源

l          数据抽取与清洗层

l          统计分析与数据挖掘层

l          数据表示

l          决策支持与展示

（ 1 ）数据源层

根据供应链物流管理的实际需求，考虑到巨大的数据量，数据分析不宜直接架构在实际业务数据库之上。为了减轻业务数据库的负担和保障核心业务数据的安全性，我考虑构建另外一个物理上独立的分析库，该分析库从逻辑上包括两个部分：克隆的业务库和分析数据库。

克 隆库的数据是实际业务数据库的真实再现，是基本的统计分析和数据挖掘功能的数据基石。由于很多统计分析结果存在不可变更性，比如采购、销售、库存、物流加 工业务的月报、年报及汇总信息等，为了便于快速的查询和统计，这些信息可以存在分析数据库中，以提高运行效率。另外，在数据分析过程中必然产生大量的临时 结果，根据情况也可以存放在分析库中。

   

图 1-4     商业智能的 5 个层次

 

（ 2 ）数据的抽取与清洗层

分析库在构建时，有一次从业务库的数据迁移过程。但是，随着业务库的不断膨胀与更新，分析库必须保持与业务库的同步，才能保证分析结果的真实性。

有两种方案可供选择：实时同步与定期抽取。

实时同步方式要求业务数据在写入业务数据库时，同时提交到分析库中的克隆库；或者由业务库触发写操作，完成这一同步功能。这种方式对于数据库的处理性能有较高的要求，当提交庞大的数据量时，不免会影响交易处理的时效。但是它适合于实时分析系统。

定期抽取方式依赖于用户的实际状况，在交易量较少或者长时间没有交易处理的时候激发数据同步操作，基本上不增加业务处理的时间复杂性。依赖于对于分析结果的实时程度的要求，比如可以考虑在每日或者每两日凌晨启动同步操作。

为了满足未来可能的分析时效需求，我将同时考虑实时同步和定期抽取两种方式，由企业根据需要自行设置。

为了提高分析精度，在数据抽取的过程中，系统将根据需要自动清洗数据。

（ 3 ）统计分析与数据挖掘层

经过清洗之后的数据只有施加以相关的统计分析和数据挖掘模型，才能真正从中提取潜在的、对企业有价值的指导性信息。因此统计分析和数据挖掘层是本分析系统的核心层。

（ 4 ）结果数据的表示

       分析的直接结果是一些有特定含义的数字或符号，必须经过表达才能理解。

（ 5 ）决策支持与展示层

基于交易分析、商务分析、事务分析基础之上的统计分析和数据挖掘层的输出结果作为决策支持与表示层的输入，用以解释和表达分析结果，展示企业运作的推介信息。

§1-2      技术路线

功能设计的目标是如何满足供应链物流系统的商业需求，而技术设计的目标则是采用那种技术以及如何从技术上实现系统的功能目标。

§1-2-1    技术设计目标

l          实用性

技术的目的就是满足系统的功能，这一点是技术设计的基本原则， 我的根本目的就是能最大限度地满足供应链物流系统的商业需求。本方案所推荐的主要技术具有成熟、稳定、实用的特点。考虑到系统开发成功之后将立即投入到企业日常业务应用中，因此我将实用性放在首位，既便于用户使用，又便于系统管理。

l        面向未来需求的高度延展性

面对用户需求的纷繁复杂和销售市场的千变万化，供应链物流企业必然不断的修正和完善营销模式和业务流程。因而，新的商业需求将不断产生，从客观上要求技术模式具有高度的开放性和可伸缩性，降低系统的维护和开发成本，以便在必要的时候能一步跨入未来。

l        技术先进性、开放性与标准化原则

本方案所采用的系统平台、数据库技术和开发工具均体现了软件技术的先进性和开放性。并考虑到未来的发展特点，我把技术标准性放在重要位置，所采用产品和技术都遵循业界最新标准。我完全可以做到使系统的硬件环境，通信环境，软件环境，操作平台之间的相互依赖减至最小。

l        容错与负载均衡技术保证物流业务受理过程的可靠性和健壮性

一个不可靠的、不健壮的或者说容易经常发生崩溃的系统对于供应链物流服务企业而言是不可接受的。

我在本系统的设计中，充分考虑到了业务受理过程的健壮性。系统支持多服务器容错与流量均衡策略，使得并发业务操作可以有多个服务器均衡分担，从而提高了业务受理速度。如果某个服务器坍塌，那么其他服务器会自动接管该业务进程，而这些对于用户而言，是透明的。

l        保护企业在信息化进程上的现有投资

本系统的设计必须充分利用供应链成员企业对系统、应用、信息和人力的现有投资，实现对原有系统的透明移植和无缝集成。也就是说，要在现有投资和不影响企业目前信息系统正常运作的前提之下而构筑未来。

l        系统安全性和易用性的完美统一

多级层次化权限认证体系和数据加密传输措施以及多层分布式应用逻辑保证了系统的安全性；系统的快速响应和亲善友好的导航措施力争使不太会使用电脑的人也能游刃有余地操作，真正享受完全的所见即所得。

§1-2-2    软件技术模式的演进

（ 1 ）两条技术路线的趋同化——— 多层分布式应用

在目前应用系统的发展过程之中，有两条貌似不同的系统结构正在持续的发展。一条是传统的应用系统，如 MIS 、商业软件包和工具程序。它们在 Windows 平台上使用原生代码，体现为非常华丽的图形用户界面（ GUI ）。但是后来也发展成为类似于公文包结构的分布式多层应用系统，以增加系统的延展性。

另一条则起源于 Internet/Intranet 技术的流行，造成了无数新的商机，这些应用系统集成了 Internet/Intranet 的技术能力，从早期的利用 HTML 查询静态数据集开始，发展为现在的电子商务技术，而且能在浏览器中执行 MIS 、 ERP 、 eSCM 等大型复杂的系统。

尽管两条技术路线使用的环境不同，但是它们的技术模式是一致的，最终都发展成为多层分布式应用架构和基于服务器的集中处理。

多层分布式应用技术和基于服务器的集中处理模式是目前供应链物流应用技术的必然发展趋势。

供应链物流企业信息化管理平台当然应该是一个多层分布式应用系统。

（ 2 ）软件开发技术的演进 ———基于 Web 服务的开发

 

图 1-5     软件开发技术的演进

  当 Internet/Intranet 的应用刚开始发展时，第一轮应用开发是偏向文件导向的。在当时 Web 的主要应用是使用编辑器编辑 HTML 文件，制作信息内容以提供给用户阅读和查询使用。

但是这种方式的不经济性和低效率很快暴露无遗，于是出现了众多脚本语言争雄的局面，导致了诸如 ASP 、 JSP 等快速应用构建工具的出现，这一阶段就是程序语言和网络程序员最为风光的程序导向型阶段。

Internet/Intranet 的发展是如此的迅速，以至于传统开发工具跟不上网络应用的发展。于是以服务为导向的 Web 应用开始兴起，这个便是目前方兴未艾的服务导向型开发阶段。

Web 服务使用 Soap 作为组件间的调用协议，使用 HTTP 页面作为客户端与服务端之间的数据传输方式，使 XML 作为数据封包的标准。因而它具有跨平台调用和无缝集成组件服务的卓越性能。

供应链物流企业信息化管理平台 以 Web 服务的方式开发。

（ 3 ） Win32 、 Java Platform 、 . Net 、 Linux 与 Unix ，我选择谁 ———跨平台开发

由于物流过程中信息的流动跨企业进行，物流系统必须实现跨地区的信息实时传输、远程数据访问、数据分布处理和集中处理的结合、多个异地局域网连接等功能。 Internet 和 Web Service 技术的出现有效在实现了上述功能。

但是， Web Service 只能解决跨平台信息交互的瓶颈，不能解决跨操作系统的开发和运行问题。那么，我的系统将支持那些平台？

l          Java Platform       由于 J2EE 使得 Java 平台成为企业核心应用的主力开发平台之一。但是， Java 应用只能用 Java 开发， JVM 机制影响了运行效率，开发成本高。

l          Win32 与 .Net        Win32 平台一直是桌面应用和中小企业应用的主流。为了摘掉“桌面操作系统”的帽子， Microsoft 推出了不依赖于开发语言的 .Net 战略，目前方兴未艾，许多独立软件供应商认为 .Net 似有取代之势。

l          Linux                    作为一个稳定、快捷、开放的操作系统， Linux 已经成为了操作系统的宠儿。现在采用 Linux 作为服务端的应用越来越多。

l          Unix                      毫无疑问， Unix 依然保持着操作系统界的王者风范。但是其开发成本高、运行费用昂贵、应用软件价格不菲，所以只能作为关键性的企业应用平台。

综上所述，我在 供应链物流企业信息化管理平台中将支持如表 1-1 所示的系统运行平台。

 

 

表 1-1  供应链物流企业信息化管理平台支持的操作系统

 

§1-2-3    技术模式

结合软件技术的发展趋势，考虑到供应链物流服务商的商业特点，我在本方案中拟采用基于 Web 服务的多层分布式应用技术来架构 供应链物流企业信息化管理平台 。

下面从技术架构、技术实现两个方面对本系统的技术模式作阐述。

§1-2-3-1 技术架构

一、采用多层分布式应用架构

供应链物流企业信息化管理平台 的技术架构如图 1-6 所示。

依照图 1-6 的技术架构，有如图 1-7 所示的 供应链物流企业信息化管理平台 逻辑架构。结合图 1-6 和图 1-7 ，我对主要的技术思想做一个说明。

（ 1 ）后台数据库

后台数据库可以是独立的数据库，也可以是多个数据库的集群。理论上它可以是诸如 Oracle 、 Sybase 、 MSSql 、 DB2 、 Informix 、 Mysql 、 Interbase 等 任何关系型数据库，该数据库不再承担复杂的数据处理任务，只是用来存储和管理数据，而复杂的业务处理逻辑则交由中间层应用服务器处理。严格说来，它是系统 的数据容器。通过“减压”之后的数据库服务器将在应对大容量并发数据访问的操作中显示卓越性能，这也是多层分布式应用的一个优势之一。

我注意到，除了本地业务数据库之外，还有本地分析数据库和可能的多个远程数据库。本地业务数据库用来存放企业的商业数据，但是随着业务的不断开拓，供应链条物流企业很可能继续在世界各地开设新的分公司，如果采用独立系统结构，便存在本地数据和远程数据库的同步问题。

 

图 1 — 6  供应链物流企业信息化管理平台的技术架构

（ 2 ）中间层应用服务器

我 的工作流引擎位于中间层应用服务器上，该引擎以智能中间件的形态存在。企业所有的核心业务处理均在该中间件上实现，它也是唯一的直接与后台数据库发生信息 交换的实体。该中间层接受所有的来自客户端的业务处理请求，并根据请求类型自动派发到不同的业务处理实体，由业务处理实体负责从数据库获取数据并且执行事 实上的业务处理操作。业务处理完成后，其结果通过中间层返回给客户端。

对于供应链物流管理系统而言，电子商务是一个重要的业务增长点，对于来自于电子商务的交易信息和客户信息的处理甚为必要。因此，必须将电子商务的交易数据同步到本地业务数据库，而这一工作也由位于中间层应用服务器完成。

 

 

图 1-7     供应链物流企业信息系统逻辑架构

 

（ 3 ）瘦客户端

由于中间层的存在，使得后台数据库和前台客户端的大部分操作得到释放，呈现出“两头轻、中间重”的纺锤形，这个便是瘦客户端的由来。本系统中，瘦客户端有两种实现方式：基于图形界面的 GUI 和基于 Web Server 浏览器的方式。

在供应链物流企业信息系统中， GUI 和浏览器的区别从操作上讲仅仅在于发布形式的不同（采用浏览器不要在客户端作原始发布和更新管理，而对于 GUI ，这些必不可缺少），而不存在 GUI 的效率低于浏览器的说法。实施上，如果设计得好， GUI 比较浏览器，效率尤佳。

二、这种架构给我带来什么

稳定的、可伸缩的体系架构是一个应用系统充满生命力的必要前提。实施基于该结构的供应链物流系统，对于供应链物流服务商无不裨益。

l          节约维护成本                 一旦业务需求发生变化，只需要对位于中间层的工作流引擎做变更，而不至于影响到客户端，极大地节省了维护量。尤其是将来企业的业务网络分布到不同的区域时，这种优势更为明显。

l          增强系统的延展性          由 于中间层工作流引擎被设为一个组件容器，如果需要增加新的商业处理模块，那么在组件容器中增加以组件形态存在的业务处理实体即可满足要求；系统还可以很方 便的与企业已经存在的和未来即将实施的系统平滑挂接；当客户端数量过多或者业务负荷过重，更可以采用多个工作流引擎做流量均衡。

l          商业组件的重用              组件容器中的业务处理实体均以组件方式存在，它们可以在任何时候根据需要重复使用，提高了软件生产率。

l          便捷的远程访问              作为企业的决策层甚至是业务受理人员，当你出差在外，或者正在进行一次重要的商务谈判，需要知道公司近期的运作状态或业务处理进展，最好的方式莫过于使用本系统提供远程访问功能。不用担心，无论是 GUI 还是浏览器，都能让你享受到运作如飞的快感。

l          系统更加安全                 应用服务器隔离了 Web 或者企业瘦客户机与数据库的直接联系，使得外界无法直接访问业务数据库，客观上增加了系统的安全性。

§1-2-3-2 技术实现

前面我讨论了系统的技术架构，这里我继续讨论实现这一架构的 Web Service 技术。

一、 Web Service 技术是什么

Web Service 是一种以 SOAP 为轻量型传输协议、以 XML 为数据封装标准、基于 HTTP 的组件集成技术。

 

 

图 1-8     Soap 允许各种组件模型和实现技术集成在一起

目前流行的主流组件技术大致有如下几种： Corba 、 Dcom/Com+ 、 EJB 等。 似乎每一种技术诞生之日起，便号称是最具延展性和开放性的技术，并且将成为未来的技术标准。事实上，由于每一个厂家都不可避免的在其组件模型上留下深深的 烙印，正是由于这一个性的存在，使得不同厂家的不同组件模型之间无法顺畅的交流，甚至不同厂家的同一类型组件产品之间也未必能平滑握手。这个便是 Web Service 诞生的理由。

Soap 技术是 Web Service 的核心，它以 XML 的标准格式封装数据包，其中封装的沟通信息是以文本方式来表达的，并且遵循标准的封装规则。如图 1-4 所示，这意味着任何组件模型、开发工具、程序语言和应用系统只要支持 XML 和文本格式的数据，就可以顺利的使用该技术。而现在所有组件模型、开发工具、程序语言、应用系统和操作系统都支持 XML 和文本格式，当然就可以完全支持 Soap 了。

二、 Web Service 技术给我带来什么

软件技术的发展是这样的快，当我昨天还在讨论如何实现各种组件模型的时候，今天 Web Service 已经给了我组件之间相互沟通的机制。 Web Service 技术应用在供应链物流管理系统，将极大提高系统的延展性，从根本上保护了企业的信息投资。

l          沟通过去与未来                 我注意到，几乎所有的企业在信息化进程上已经有了长远的规划和相当力度的投入。那么本系统如何与企业现有系统无缝集成，将是一个必须解决的问题；而且，随着信息化进程的逐步提高，将来会有更多的、更复杂的应用需要和现有系统集成。那么，采用 Web Service ，这一切将变得轻松自如。

l          真正的跨平台应用             跨平台应用的开发经历了三个阶段。第一轮是 HTTP 的出现，使得不同平台和操作系统可以通过浏览器相互访问；第二轮是 Java 语言的兴起，它提供了跨平台开发的契机； XML 语言的闪亮登场则是第三轮革命， XML 从底层数据包传输机制上解决了跨平台信息交换的瓶颈，从而使得不同的组件协议之间能够顺畅的交流，因而基于 XML 的 Web Service 才是真正的跨平台应用。

l          其他优势                           作为 Web Service 技术核心的 Soap 是一个开放的标准协议；它不仅突破了应用壁垒，而且能够结合企业防火墙和内部信息系统，同时提供安全和集成的应用环境；允许企业封装任何自定义信息，而不需要修改应用系统的源代码，提供了强大的系统弹性。

§1-3 数据库系统模型

这里我依照供应链物流企业的实际需求和信息工程的原理界定数据库系统的基本目标和层次划分，并给出数据库系统的逻辑结构。

一、数据库系统设计目标

根据企业的不同管理层次和管理对象，建立逻辑清晰严谨、层次结构分明、相对独立稳定、数据冗余低、共享程度好、安全性能强、维护效率高、扩充能力大便于操作处理的数据库系统。

二、数据库系统层次划分

供应链物流管理系统的运作过程实际上是商业数据的处理和流动的过程。数据作为系统的基础和核心，其结构是稳定的，但其内容却是流动的。

每一次对数据的访问或处理的过程，随着流动的范围、访问的频度、处理的方法和面向的对象不同将会有相当大的区别。这一区别一方面反映了实际管理工作和业务受理人员的层次特性，另一方面也体现了数据库的层次关系。

因而，数据库的设计应该充分体现这一现实特性。

该项目的数据库系统共划分为五个层次：

l          管理层

l          信息发布层

l          数据处理层

l          数据表示层

l          底层信息源

三、数据库系统逻辑结构

上述五个层面构成了供应链物流企业信息化管理平台中数据库部分的整体逻辑结构，如图 1-9 所示。

1 、底层信息源                    主要由信息系统原始模型、外部子系统构成。外部子系 统主要是企业已有的数据获取系统，如购销存系统、财务管理系统、人事管理系统、 ERP 等。而信息系统主要原始模型包括企业的业务数据库和远程业务库，形式上体现为交易的、业务的、商务的、事务的原始数据、历史资料及动态受理的信息等。

2 、数据表示层                    与底层信息源紧密结合，依照各功能模型，对各类数据进行分类、清洗、规则化， 包括业务的、商务的、交易的、事务的等各种具体素材的规范处理功能，以便提交到数据处理层处理。

3 、数据处理层                    它是图中业务数据库和可能的备份数据库与其上的第 一 个分布式数据库所包含的内容。该层的主要功能是各类数据处理。汇总、统计由数据表示层上报的业务数据；处理销售、采购、加工、库存、配送等业务数据和各类 查询结果、报表统计、经营计划制定等日常工作以及来自高层的各类查询的数据获取功能。其处理结果一部分返回本层业务数据库（有可能的话，同时提交备份数据 库），一部分递交库存数据库或供决策层使用的辅助决策数据库和计划与控制数据库。

4 、信息发布层                    信息发布层是数据库系统中直接面向用户一个层 面。其内容来源于各个子数据库：（ 1 ）经 Web 服务器上的 Web 应用处理和格式化之后，业务受理结果提交给用户浏览；（ 2 ）经应用服务器分析之后，业务受理结果提交给 GUI 用户；（ 3 ）部分业务受理结果返回企业内部系统管理和商业智能子系统。

 

 

图 1-9  供应链物流企业信息化管理平台数据库模型

5 、管理层                           管理层是整个系统的最顶层，面向管理者。该层独享商业智能 子系统和高层独享数据库，提供各项分析指标以供领导决策之用。设立辅助决策功能是为将来决策型专家系统的开发提供基础。

 

 

§1-4      工作流技术在 eSCM 物流企业信息化管理平台中的应用

在功能模型中，我采用工作流引擎技术驱动核心业务的运作，工作流引擎成为了本系统的应用驱动核心。这里，我对本系统采用工作流引擎技术的理由与优势做一探讨，具体的工作流引擎技术数学模型在以后的数学模型中描述。

§1-4-1    目前现状

物流信息化管理平台已经有多年的发展历史了，但是成功的却不多见。从技术上究其原因，不外乎如下几点：

l          没有良好的数学模型            按照软件工程学的观点，良好的数学模型是系统设计的坚强基石，可是开发商在开发应用时，往往为了省时省力而忽略了数学模型，导致系统没有完善而成熟的理论支持，对开发进程中遇到的技术问题采取退而求其次的方法。

l          系统缺乏扩展性                   尽管每个开发商都宣称自己的系统具备良好的可扩展性，但是实际上真正做到的不多见。

l          应用模式固定                      大 部分系统在开发过程之中把系统逻辑完全绑定在用户的具体需求或具体业务流程上，当用户需求发生变更时，不得不重新开发系统或者大量修改源代码。由于事先缺 乏统一的规划，导致不断的给系统打“补丁”，结果就像“滚雪球”一样，系统越来越庞大，其效率低下和稳定性不良等问题接踵而来。

为了解决上述问题，我提出并实现了“基于动态流程的工作流模型 ---SuperFlow ” 。基于这一模式，可以有效的解决上述诸多问题。

 

§1-4-2    动态业务工作流引擎的应用

一、企业需要什么

商 业信息化的根本目的就是为了提高效益，而前提是信息系统能够真正按照商业逻辑要求去运作。但是企业花钱购买的信息系统往往是软件开发商针对大部分企业的共 性而设计的，很难满足形态各异的企业的个性要求，结果是企业虽然购买了信息系统，但是还必须花大量财力要求软件开发商作二次开发。而且一旦企业的业务流程 发生变化，可能会导致后续的多次开发和维护。

导致上述现象的原因就是目前几乎所有的业务信息系统都是将企业的业务逻辑和软件系统的控制逻辑捆绑在一起，使得一旦企业的业务逻辑发生变更，将全面的影响到软件系统的控制逻辑，因而必须修改大量源代码甚至重新开发。

Superflow 有效地解决了上述问题。它隔离了软件系统的控制逻辑和企业的业务逻辑，使得业务逻辑的变更对于控制逻辑而言是透明的。利用该引擎开发的业务信息系统可以根据具体业务需求量身定制个性化的业务流程，而不用修改控制逻辑，甚至无需修改源代码 。

二、 Superflow 能为企业做什么

Superflow 是一个方便高效的中间层工作流引擎。它解决了目前在开发具有业务流程的系统中出现的没有良好数学模型、系统不易扩充、业务流程无法变更、二次开发困难等弊端。

该引擎用关系模型的理论解释和表达能用有向图表示的任意复杂 的业务流程；允许用户在该平台上自定义 新的业务流程和更改 已有的业务流程；用户能以构件的方式定义业务动作、组合业务动作以实现满足未来需求 的业务流程； 真正做到任意复杂业务流程的全自动 配置和完全意义 上的流程重组。

系统提供了如下主要功能：

流程设置

流程重组

流程跟踪

时限设置

时限跟踪

业务动态分配和分配方式管理

业务主动通知

部门管理

业务组管理

用户管理

授权管理

多服务器容错与负载均衡

上述所有功能均在引擎上实现，客户端只需调用引擎服务器接口方法即可。在本项目中，我将在商业处理流程中使用这一独创的先进技术。

最后

以上就是暴躁画板为你收集整理的第三方物流3PL/SCM系统设计技术的全部内容，希望文章能够帮你解决第三方物流3PL/SCM系统设计技术所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。