物流系统的建立过程_第三方物流3PL/SCM系统设计技术
本文关键词：物流系统设计技术，由笔耕文化传播整理发布。
第三方物流系统设计技术
根据供应链物流管理的要求，功能模型的设计应瞄准如下目标：
在供应链一体化运作和管理中，实现信息化是最基本也是最重要的管理目标。在供应链周期中，端到端的交易执行从最初供应商订单到最终送达客户和客户支付过程中物品、信息和资金的无缝流动，是供应链管理的最重要原则，实现这一目标的基本手段就是供应链管理信息化系统。
一个运行稳健的供应链物流管理系统应该是物流、信息流和资金流的高度协调和统一，任何一种“流”出现断点不仅会使得交易和管理搁浅，而且会对企业的运作过程导致不可预料的灾难。
对于业务受理过程的跟踪和分析，可以从统计分析的角度挖掘减少失误、节约交易处理时间、降低对人力资源占用的优化手段。我的供应链数据分析系统将贯穿于供应链管理的各个阶段，动态分析和实时洞察企业的采购、销售、和配送规律以及与其他贸易合作伙伴的关系，真正建立高效的物流配送系统。
供应链物流企业面对的是瞬息万变的市场，企业家们不得不随时调整和更改先有的商业模型和业务流程运作方式。因而，供应链物流企业的功能模型应该具备良好的可伸缩性，以满足为适应市场而不断调整的商业运作模式。
商业模型是基础，功能模型是商业模型的应用体现。
在设计功能模型的过程中，我依然采用层次结构的方法来观察和分析应用系统的功能结构。这里的功能模型仅仅从结构上对未来应用系统的功能结构作了分类与描述，其中每一个子系统涉及到繁多的具体业务操作过程和功能模块，等我有时间的时候，会在应用设计中会有详细描述，这里不做赘述。
无论是物流、信息流还是资金流，在应用系统的运作过程中，本质上都体现为数据的流动。从系统设计的角度看，数据库层位于应用系统的最低层，是一切系统操作与应用功能的基础。
l 数据的层次性、一致性与安全性
数据的流动过程是数据形式的变化与处理过程，在数据库中体现为数据的层次性：由具体的凌乱的数据到规范的格式化数据和经过处理的数据结果等，无不体现为层次性；此外，数据的一致性与安全性是所有数据库系统必须提供的管理目标。
l 数据的存储与管理者，而非业务逻辑的处理
系统管理与配置层是系统运行的基础。该层基于数据库，对上层提供基础的系统管理配置功能和运行保障。
该层包括四个大的部分：系统管理、应用配置管理、商业基础资料管理、商业规则管理。
无论从系统应用的角度还是从商业运作的角度，上述四个部分都是系统运行的最基本要素。
从商业运作的角度看，有了数据和基础的商业资料的管理，似乎可以着手核心业务的运作了。
但是，作为一个统一的、协调的整体，我知道供应链物流企业的核心业务无一不是在业务规则的指导下，沿着一定的业务路线运作的。因此，所有的业务运作都有其特殊的规律，这些规律体现为一定的业务流程。
因此，在进行核心业务的运作之前，必须考虑一个统一的、稳健的业务流程驱动方式，使得所有的核心业务均在这种方式的有效驱动下，平滑流畅的运作。这就是工作流引擎。
工作流引擎
工作流引擎是我这个系统的重要特色和核心技术。所有核心业务的操作均在工作流引擎的驱动和控制下运行，因此，我将专门对工作流引擎的数学模型作分析。
应用门户协同引擎
独立系统运作的方式是所有的分公司共享一个信息平台，采用互联网技术进行信息交换。但是，这样的系统对于企业的网络环境和基础架构要求很高。
多系统协同的方式是每个分公司采用独立的系统平台，但是系统平台之间采用应用门户协同引擎来协调运作。这种方式对基础架构与网络环境的要求不高，但是难以保障总公司对各个分公司的实时性管理。
至于供应链中成员企业之间的信息交互则通过远程访问与信息发布子系统完成。
核心业务是提升企业价值和核心竞争力的主要源泉。在工作流引擎的驱动之下，企业核心业务的运作可以划分为十个子系统。下面十个子系统的具体功能模块将在以后有时间的时候再作描述，油画先生我太忙了。
根据供应链物流管理的实际需求，考虑到巨大的数据量，数据分析不宜直接架构在实际业务数据库之上。为了减轻业务数据库的负担和保障核心业务数据的安全性，我考虑构建另外一个物理上独立的分析库，该分析库从逻辑上包括两个部分：克隆的业务库和分析数据库。
<w:wrap type="topAndBottom">
克隆库的数据是实际业务数据库的真实再现，是基本的统计分析和数据挖掘功能的数据基石。由于很多统计分析结果存在不可变更性，比如采购、销售、库存、物流加工业务的月报、年报及汇总信息等，为了便于快速的查询和统计，这些信息可以存在分析数据库中，以提高运行效率。另外，在数据分析过程中必然产生大量的临时结果，根据情况也可以存放在分析库中。
分析库在构建时，有一次从业务库的数据迁移过程。但是，随着业务库的不断膨胀与更新，分析库必须保持与业务库的同步，才能保证分析结果的真实性。
有两种方案可供选择：实时同步与定期抽取。
实时同步方式要求业务数据在写入业务数据库时，同时提交到分析库中的克隆库；或者由业务库触发写操作，完成这一同步功能。这种方式对于数据库的处理性能有较高的要求，当提交庞大的数据量时，不免会影响交易处理的时效。但是它适合于实时分析系统。
定期抽取方式依赖于用户的实际状况，在交易量较少或者长时间没有交易处理的时候激发数据同步操作，基本上不增加业务处理的时间复杂性。依赖于对于分析结果的实时程度的要求，比如可以考虑在每日或者每两日凌晨启动同步操作。
为了满足未来可能的分析时效需求，我将同时考虑实时同步和定期抽取两种方式，由企业根据需要自行设置。
为了提高分析精度，在数据抽取的过程中，系统将根据需要自动清洗数据。
经过清洗之后的数据只有施加以相关的统计分析和数据挖掘模型，才能真正从中提取潜在的、对企业有价值的指导性信息。因此统计分析和数据挖掘层是本分析系统的核心层。
基于交易分析、商务分析、事务分析基础之上的统计分析和数据挖掘层的输出结果作为决策支持与表示层的输入，用以解释和表达分析结果，展示企业运作的推介信息。
功能设计的目标是如何满足供应链物流系统的商业需求，而技术设计的目标则是采用那种技术以及如何从技术上实现系统的功能目标。
面对用户需求的纷繁复杂和销售市场的千变万化，供应链物流企业必然不断的修正和完善营销模式和业务流程。因而，新的商业需求将不断产生，从客观上要求技术模式具有高度的开放性和可伸缩性，降低系统的维护和开发成本，以便在必要的时候能一步跨入未来。
本方案所采用的系统平台、数据库技术和开发工具均体现了软件技术的先进性和开放性。并考虑到未来的发展特点，我把技术标准性放在重要位置，所采用产品和技术都遵循业界最新标准。我完全可以做到使系统的硬件环境，通信环境，软件环境，操作平台之间的相互依赖减至最小。
一个不可靠的、不健壮的或者说容易经常发生崩溃的系统对于供应链物流服务企业而言是不可接受的。
我在本系统的设计中，充分考虑到了业务受理过程的健壮性。系统支持多服务器容错与流量均衡策略，使得并发业务操作可以有多个服务器均衡分担，从而提高了业务受理速度。如果某个服务器坍塌，那么其他服务器会自动接管该业务进程，而这些对于用户而言，是透明的。
本系统的设计必须充分利用供应链成员企业对系统、应用、信息和人力的现有投资，实现对原有系统的透明移植和无缝集成。也就是说，要在现有投资和不影响企业目前信息系统正常运作的前提之下而构筑未来。
多级层次化权限认证体系和数据加密传输措施以及多层分布式应用逻辑保证了系统的安全性；系统的快速响应和亲善友好的导航措施力争使不太会使用电脑的人也能游刃有余地操作，真正享受完全的所见即所得。
多层分布式应用
尽管两条技术路线使用的环境不同，但是它们的技术模式是一致的，最终都发展成为多层分布式应用架构和基于服务器的集中处理。
多层分布式应用技术和基于服务器的集中处理模式是目前供应链物流应用技术的必然发展趋势。
供应链物流企业信息化管理平台当然应该是一个多层分布式应用系统。
Win32
Win32
.Net
J2EE
Linux
Unix
Thin Client
√
√
√
Application
Server
√
√
√
Web Server
√
√
√
Database Server
√
√
√
√
下面从技术架构、技术实现两个方面对本系统的技术模式作阐述。
一、采用多层分布式应用架构
我注意到，除了本地业务数据库之外，还有本地分析数据库和可能的多个远程数据库。本地业务数据库用来存放企业的商业数据，但是随着业务的不断开拓，供应链条物流企业很可能继续在世界各地开设新的分公司，如果采用独立系统结构，便存在本地数据和远程数据库的同步问题。
供应链物流企业信息化管理平台的技术架构
我的工作流引擎位于中间层应用服务器上，该引擎以智能中间件的形态存在。企业所有的核心业务处理均在该中间件上实现，它也是唯一的直接与后台数据库发生信息交换的实体。该中间层接受所有的来自客户端的业务处理请求，并根据请求类型自动派发到不同的业务处理实体，由业务处理实体负责从数据库获取数据并且执行事实上的业务处理操作。业务处理完成后，其结果通过中间层返回给客户端。
对于供应链物流管理系统而言，电子商务是一个重要的业务增长点，对于来自于电子商务的交易信息和客户信息的处理甚为必要。因此，必须将电子商务的交易数据同步到本地业务数据库，而这一工作也由位于中间层应用服务器完成。
二、这种架构给我带来什么
稳定的、可伸缩的体系架构是一个应用系统充满生命力的必要前提。实施基于该结构的供应链物流系统，对于供应链物流服务商无不裨益。
一旦业务需求发生变化，只需要对位于中间层的工作流引擎做变更，而不至于影响到客户端，极大地节省了维护量。尤其是将来企业的业务网络分布到不同的区域时，这种优势更为明显。
由于中间层工作流引擎被设为一个组件容器，如果需要增加新的商业处理模块，那么在组件容器中增加以组件形态存在的业务处理实体即可满足要求；系统还可以很方便的与企业已经存在的和未来即将实施的系统平滑挂接；当客户端数量过多或者业务负荷过重，更可以采用多个工作流引擎做流量均衡。
组件容器中的业务处理实体均以组件方式存在，它们可以在任何时候根据需要重复使用，，提高了软件生产率。
这里我依照供应链物流企业的实际需求和信息工程的原理界定数据库系统的基本目标和层次划分，并给出数据库系统的逻辑结构。
一、数据库系统设计目标
根据企业的不同管理层次和管理对象，建立逻辑清晰严谨、层次结构分明、相对独立稳定、数据冗余低、共享程度好、安全性能强、维护效率高、扩充能力大便于操作处理的数据库系统。
二、数据库系统层次划分
供应链物流管理系统的运作过程实际上是商业数据的处理和流动的过程。数据作为系统的基础和核心，其结构是稳定的，但其内容却是流动的。
每一次对数据的访问或处理的过程，随着流动的范围、访问的频度、处理的方法和面向的对象不同将会有相当大的区别。这一区别一方面反映了实际管理工作和业务受理人员的层次特性，另一方面也体现了数据库的层次关系。
因而，数据库的设计应该充分体现这一现实特性。
该项目的数据库系统共划分为五个层次：
三、数据库系统逻辑结构
<w:wrap type="topAndBottom" anchorx="page">
在功能模型中，我采用工作流引擎技术驱动核心业务的运作，工作流引擎成为了本系统的应用驱动核心。这里，我对本系统采用工作流引擎技术的理由与优势做一探讨，具体的工作流引擎技术数学模型在以后的数学模型中描述。
物流信息化管理平台已经有多年的发展历史了，但是成功的却不多见。从技术上究其原因，不外乎如下几点：
按照软件工程学的观点，良好的数学模型是系统设计的坚强基石，可是开发商在开发应用时，往往为了省时省力而忽略了数学模型，导致系统没有完善而成熟的理论支持，对开发进程中遇到的技术问题采取退而求其次的方法。
尽管每个开发商都宣称自己的系统具备良好的可扩展性，但是实际上真正做到的不多见。
l 应用模式固定 大部分系统在开发过程之中把系统逻辑完全绑定在用户的具体需求或具体业务流程上，当用户需求发生变更时，不得不重新开发系统或者大量修改源代码。由于事先缺乏统一的规划，导致不断的给系统打“补丁”，结果就像“滚雪球”一样，系统越来越庞大，其效率低下和稳定性不良等问题接踵而来。
为了解决上述问题，我提出并实现了“基于动态流程的工作流模型---SuperFlow”。基于这一模式，可以有效的解决上述诸多问题。
一、企业需要什么
商业信息化的根本目的就是为了提高效益，而前提是信息系统能够真正按照商业逻辑要求去运作。但是企业花钱购买的信息系统往往是软件开发商针对大部分企业的共性而设计的，很难满足形态各异的企业的个性要求，结果是企业虽然购买了信息系统，但是还必须花大量财力要求软件开发商作二次开发。而且一旦企业的业务流程发生变化，可能会导致后续的多次开发和维护。
导致上述现象的原因就是目前几乎所有的业务信息系统都是将企业的业务逻辑和软件系统的控制逻辑捆绑在一起，使得一旦企业的业务逻辑发生变更，将全面的影响到软件系统的控制逻辑，因而必须修改大量源代码甚至重新开发。
二、Superflow能为企业做什么
系统提供了如下主要功能：
流程设置
流程重组
流程跟踪
时限设置
时限跟踪
业务动态分配和分配方式管理
业务主动通知
部门管理
业务组管理
用户管理
授权管理
多服务器容错与负载均衡
上述所有功能均在引擎上实现，客户端只需调用引擎服务器接口方法即可。在本项目中，我将在商业处理流程中使用这一独创的先进技术。
本文关键词：物流系统设计技术，由笔耕文化传播整理发布。
本文编号：148551
本文链接：https://www.wllwen.com/wenshubaike/kcsz/148551.html
