出家如初,成佛有余

电子商务系统之电子分销平台建设

Posted in Uncategorized by chuanliang on 2007/12/15

1、电子分销(E-distribution)的优势

    电子商务对企业内部资源管理,原材料采购,生产的组织、协调和产品的广告、宣传、销售产生深远的影响。电子商务最大限度地简化了产品的供应链,缩短了厂商与用户之间的距离,营销渠道日趋扁平化。电子分销(E-distribution)是指借助电子商务的手段来改造传统的分销渠道,正如电子分销的四大优势所说的,与传统的分销渠道相比,电子分销的优势表现为:

  • 扩展传统分销渠道
  • 打通传统分销链信息流
  • 扁平化传统分销渠道
  • 降低交易成本

2、电子分销平台建设思路

2.2、思考出发点

  对于我而言,思考电子分销并不是要做一个电子分销管理的产品,而是希望通过对电子分销管理的思考,能够理解电子分销的核心理念,然后能够结合具体的行业的电子商务平台的建设,融合到电子商务平台的系统建设中。因此在思考时候并不追求完备性、严密性,而在于实用性。

  对于大部分的合作伙伴、代理商而言,大部分并没有现成的IT信息系统,他们对于诸如电子商务系统、ERP、CRM、SCM等都毫无任何概念,也分不清其差别何在,因此电子分销系统的集成性是至关重要的,电子分销系统在满足具体电子商务系统业务需求的情况下,应当提供一体化的ERP、CRM、财务(帐务、结算、清算、支付)、SCM、BI等系统的功能,为众多不具有IT系统的代理商提供一体化、一站式的服务。

  电子分销平台建设的重点是服务,对代理商的营销过程提供全程的增值服务,而不是产品的销售过程本身。通过服务,在价值链中扮演增值服务提供商作用。

  社区是电子分销平台建设的重要内容,以信用体系、积分体系为核心,通过开放式的社区,营造良好的社区气氛,吸引代理商参与社区的建设,提高其粘着度。

 

2.1、建设步骤

分销企业常见的业务系统实施顺序如下:

(1)总部订单管理系统:对各种渠道的客户订单进行统一采集和处理。建立高效的客户自动补货系统,帮助客户自动生成订单或建议订单,并及时、准确地跟踪订单执行情况,包括生产、库存、物流配送等数据。此系统可以使得销售订单与生产计划集成,实现按单生产,并有效降低材料和产品库存。

(2)初期BI系统:在总部订单管理系统的基础上,可对历史销售数据按品种、规格、区域等属性进行有效汇总与分析。充分利用历史的销售数据进行多方位的剖析,并将分析结果作为销售预测的支持。
(3) 分销系统:将信息触角进一步深入。收集分销渠道的订货、库存、销售数据,从而大大降低总部订单数据在及时性、准确度上面的缺陷。在管理上需要配套将分销渠道提供及时准确的数据作为考核评估的一项指标。

(4) BI系统(深化应用):在分销系统基础上,将收集的分销渠道的订货、库存、销售数据按照产品、渠道、地区等进行分析统计,向相关管理层和分公司提供及时准确的报表。

(5) 终端管理系统:对于拥有专柜、专卖店等通路形态的分销企业,终端系统可及时了解各个门店的预订单和安装单数据,有效地指导公司整体销售预测和生产计划。且终端系统还可作为会员管理系统,进行原始数据的采集、会员销售产品分析、会员促销查询及会员卡管理等等,并提出一定的分析报告。

(6)营销费用管理系统:在各级销售数据较齐备的基础上,将大批量重复、可量化的营销费用审核工作交由IT系统执行,并实现营销费用的预算管理。包括制定营销政策和计划时,能够有效利用历年的详细数据;在预算执行过程中,进行各套预算之间、实际执行情况与预算之间、以及当期实际执行情况与历史同期的差异分析比较,产生预算执行分析的各种报表;在费用发生后,进行更及时、完整和精确的统计分析报告。

 

3、电子分销的研究案例

3.1、航空旅游

淘票网:http://www.51taopiao.com

航旅通:http://www.sune365.cn

易行天下:http://www.yeexing.com

3.2、数字内容

骏网在线:http://www.junnet.cn/

云网:http://www.cncard.com/

3.3、网上购物

进宝网:http://www.jinbao.com

北斗手机网:http://www.139shop.com/

 

4、参考资料

http://www.cww.net.cn/mobile/html/2007/11/21/200711211017177371.htm

http://www.amteam.org/print.aspx?id=451758

http://www.ecsoo.com/yingxiao/2006-12-24/k1398.htm

http://www2.ccw.com.cn/05/0504/d/0504d06_1.asp

http://blog.vsharing.com/amtconsulting/A582386.html

学习电信BOSS系统好榜样-电子商务系统建设思考3:设计原则

Posted in Uncategorized by chuanliang on 2007/12/09

1、系统设计原则

  • 高安全性:

    安全性是指确保系统安全不会被危及的能力。安全性是电子商务系统建设的首要前提。系统采用符合有关规定的信息安全标准、技术标准、业务标准;保证电子商务业务处理系统的安全性,以及数据信息资料的完整性、可靠性、安全性、不可抵赖性;在构建电子商务系统架构时,应该把整体系统架构尽可能地分割成各个子功能模块,在将一些子功能模块暴露为外部用户可见的服务的时候,要围绕各个子模块构建各自的安全区,这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击,也可以保证其他模块相对安全。

  • 高性能:

    性能是指系统提供的服务要满足一定的性能衡量标准。对于电子商务系统的系统的整体性能度量标准主要为每个用户访问的系统响应时间以及系统能够处理的交易量(每秒)的能力。在建设时候应当从分布式文件系统、海量数据处理、数据库(交易数据库,分析数据库)、软件架构、应用服务器、网络等方面对系统进行全方位的优化,达到系统性能动态的最优化。

  • 高可用性:

    可用性是指一个系统应确保一项服务或者资源应该总是可被访问到的。电子商务系统每天都处理着大量的业务数据,任何时刻的系统设备故障都有可能带来损失,这要求系统具备很高的稳定性和可用性,以及很高的平均无故障率。保证故障发生时系统能够提供有效的失效转移或者快速恢复等性能。硬件环境消除单点故障,实现双机容错和负载均衡功能。保证系统的高可用性,即7×24小时不停机的工作模式。通过在环境中设置冗余组件和错误恢复机制,虽然一个单独的组件的错误会对系统的可靠性产生不良的影响,但由于系统冗余的存在,使得整个系统服务仍然可用。

  • 高扩展性:

    可扩展性是指在不影响现有系统功能的基础上,为系统添加新的功能或修改现有功能的能力。系统的建设既充分体现系统业务的特点,充分利用现有资源,合理配置系统软硬件;又着眼建成后使用,具有良好的扩充能力,可以根据不断增长的业务需求,能够随着信息技术的发展而不断地平滑升级。应用系统的开发做到功能完善、使用方便、符合实际、运作高效。

  • 高可靠性:

    可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时,电子商务系统必须能够持续处理需求访问,并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时,不能维持它的可靠性,那么实际上这个系统也并不具备可升级 性。在构建电子商务系统架构的时候,可靠性也是必须要着重考虑的问题。要保证一定的系统可靠性,就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来 保证。只有确保每一个系统中的服务都具有较高的可靠性,我们才能保证系统整体的可靠性能够得以保障。

  • 可维护性:

    可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。对于电子商务系统这样的运营性系统,系统的可维护性原则是系统应用实施过程中的重要条件。系统易学易用,维护简便,充分考虑管理维护的可视化、层次化以及控制的实时性。

  • 可管理性:

    可管理性是指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统,应具备对服务质量需求(QoS)的系统监控能力,通过改变系统的配置从而可以动态地改善服务质量,而不用改变整体系统架构。电子商务系统必须提供管理接口让管理人员能够监控整个系统的运行情况并具备动态系统配置管理的功能。

  • 开放性:

    系统总体方案设计在体系结构、软件系统的确定方面,从系统选型到设计、开发都充分考虑“标准和开放”的原则。在应用系统的设计与开发方面,依据标准化和模块化的设计思想,在此基础上建立具有一定灵活性和可扩展性的应用平台,使系统不仅在体系结构上保持很大的开放性而且同时提供各种灵活可变的接口,系统内部也保持相当程度的可扩充性。

2、用设计原则指导电子商务系统建设

先零星记录一下目前想到的,陆续补充。

业务架构:对于运营性系统,运营过程中业务需求的持续积累是创新性产品的重要来源,每一个运营型企业都应当有自己的产品需求知识库,详细记录各种需求(合理的、不合理的)并最终体现到业务架构中去。

技术架构:技术架构和业务架构的持续积累和完善是系统建设的核心。不要指望一劳永逸地构建出高扩展性的先进架构,然后就置之不理,或者指望通过引入新的技术架构就能够解决各种问题。在运营性系统的建设过程中系统的核心架构由核心人员持续控制、维护和完善是系统建设成功的核心经验之一。

共享数据模型:在系统建设中尽早形成电子商务系统核心的共享信息/数据(Shared Information/Data,SID)模型是系统建设成功的核心要素,幸运的是可以从NGOSS借鉴很多现成模型。不管是面向对象的编程年代还是面向过程的编程年代,数据模型的可维护性、连贯性、一致性始终是系统建设的核心,必须采用专制方式由专人进行控制和维护。不管是采用top-down(由类产生数据库)还是Bottom up(由数据库生成类)情况下。

海量数据:在建设初期就要在设计和实现上考虑对海量数据的处理,保证能够将olap和oltp的功能能够从部署上(数据库、应用)分离开,保证水平扩展性。在数据模型必须考虑系统实现的效率,在遵循第3范式的基础上作一些折衷处理,通过增加冗余数据、中间表等方式,保证系统具有较高的运行效率。

 

Technorati 标签: ,,,,

学习电信BOSS系统好榜样-电子商务系统建设思考2:方法论

Posted in Uncategorized by chuanliang on 2007/12/01

    诸如B2B、B2C、C2C、电子支付这样提供SaaS的电子商务运营商所提供的电子商务系统与电信运营商的BSS/OSS类似,都为运营性系统。所谓的运营性系统是指通过软件系统持续的建设和运营为客户(主要为外部客户)提供服务。运营过程的集成性、实时性和动态性、敏捷性,要求运营商的支撑系统必须能支撑动态变化的需求和在线实时管理变化的要求,要求支撑系统的业务业务架构和技术架构能支撑新的业务模式引进和局部功能模块重构的需要,保证新的运营支撑系统的业务架构和技术架构能支撑动态变化和管理动态变化。怎样让支撑系统能够这些需求相匹配呢?

    方法论提供的不仅仅是开发过程和辅助工具的集合,更是一种思想。将这些思想运用到具体的开发实践中,会极大地提高电子商务系统的开发效率和质量。

1、SANRR方法论

   NGOSS方法论支持过程迭代,过程迭代即包括4个阶段的整体循回演进,也包括每个阶段自身的不断演进,这一方法被缩写为SANRR方法。

ngoss sanrr methodology

 

它包括五个实现步骤:

  1. 定义范围(Scope):通过对当前环境的描述和实现目标的设定,明确定义系统演进需实现的业务和功能的范围、边界。
  2. 分析(Analyze):分析新增业务或功能与原有业务或功能的关系,并用模型化语言对新增业务或功能加以定义和描述。
  3. 规格化(Normalize):分析新增业务或功能对原有业务流程、功能模型、信息模型、业务规则等的影响,将新增部分加入到原有模型中,形成一个统一的新模型。
  4. 合理化(Rationalize):通过检查和验证,进行差异分析、冲突分析和冗余分析,列出和标明出现的问题。
  5. 纠正(Rectify):针对上个步骤列出的问题,对产生问题的模型进行修改,重复4)和5)直到全部完成。

    NGOSS方法论不是重新创建的一套全新的方法,而是当今软件领域各类知识有机融合的产物,反映了当前一些最新的软件工程思想,因此,有些方法还在不断发展中,并未成熟。同时,NGOSS方法论中提出的一些方法还需要相应的可操作性的模板和工具的支持。因此,在方法论的应用上,首先要遵循的原则是充分领悟方法论所包含的思想原则、工作方法。只有在深刻领会其思想原则的基础上,才能有效利用市场上一些成熟的工具,协助电子商务系统的开发和建设。其次是不断积累相关知识,包括各种在电子商务系统开发过程中产生的中间结果和元素,为需求的不断改变和扩充提供可重用的组件,缩短业务部署和提供的时间,真正做到适应市场的变化。 

 

2、NGOSS 架构视角

ngoss views

clip_image002

    该模型提供了从两类NGOSS应用者看系统的视角,一类是业务提供者的视角,一类是系统开发者的视角。两类应用者又分别从逻辑的和物理的两个层面看系统。逻辑层面关注解决方案中技术无关内容的定义,如业务流程、业务规则、信息模型等。物理层面关注解决方案中技术相关内容的定义和具体实施,如具体实现技术选择,COTS产品选择,运行方案等。
    这样构成了四个视角,分别是业务视角、系统视角、实现视角和部署视角。

  • NGOSS业务视角:

    在这一阶段,要明确系统的业务目标、范围和职责。利用eTOM和SID描述业务过程、业务实体、业务流程和业务规则,以适合管理环境和业务提供的需要。

  • NGOSS系统视角:

    在这一阶段,主要关注系统对象、对象行为和交互操作。利用eTOM、SID和TNA来建立功能模型、构件模型、流程模型和信息模型,明确对象间的信息交互,协调一致地支持业务过程的要求。

  • NGOSS实现视角

    该视角主要关注如何利用硬件、软件和COTS,根据系统设计的要求具体实现一个特定的OSS系统。在这一阶段,要解决如何将技术中立规范中的设计转换为与技术相关的具体实现。

  • NGOSS部署视角:

    部署视角是从系统维护者的角度监控系统的执行,保证系统符合业务的需要;如果系统不满足需要,能够通过NGOSS的调整和控制机制,使其符合业务需求的变化。这些控制机制如基于过程管理中的流程定义,基于策略管理中的规则设置。

  • NGOSS知识库:

    NGOSS方法论提供了一种信息集中保存的机制,称为NGOSS知识库。NGOSS知识库中的信息来源于合作组和TMFNGOSS两个方面,包含三类知识:*现有的合作组织知识:包括软件业的已有成果,电信业的运营和业务知识*NGOSS知识:包括TMF定义的各种框架、模型、规则、技术方法等*共享知识:以上两类知识的通用部分。

NGOSS的视角实际上来自于RUP用于描述系统架构的4+1视图模型:

  • 逻辑视图(Logical View):设计的对象模型(使用面向对象的设计方法时)。与ngoss的系统视角对应
  • 开发视图(Development View):描述了在开发环境中软件的静态组织结构。 与ngoss的实现视角对应。
  • 进程视图(Process View):捕捉设计的并发和同步特征。 ngoss没有直接单独为一个视图
  • 物理视图(Physical View):描述了软件到硬件的映射,反映了分布式特性。 与ngoss的部署视角对应。
  • 用例视图(Use Cases或Scenarios):描述业务需求及场景。与ngoss的业务视角对应。

image002 

    软件架构 "4+1" 视图模型

3、eTOM业务分层模型

image

eTOM所定义的三大流程区域:战略、基础设施和产
;运营;企业管理

五大经济实体

  (1)客户:企业通过销售产品向其提供服务的对象,是业务的焦点。

  (2)供应商:向企业提供所使用的产品或资源,直接或间接地支持企业的业务;合作伙伴,企业与其共同享有的业务区域的合作对象。

  (3)股东:为企业投资从而拥有企业的股份,SP从股东处获得财务资源。

  (4)雇员或员工:为企业工作,为企业追求和实现业务目标;SP获得雇员的服务来执行企业的流程。

  (5)其他企业利益相关者:不是以股票拥有者身份与企业签有协议或承诺,包括监管者、媒体、当地社团、政府、竞争对手等。

层次结构分解

对大量内容和细节进行组织的最好方法就是以多个层次或层面来构建信息,这样层面高的视图代表着概要视图,而且每一高级层面可以分解成更详细的低一级层面,即:层次结构分解。

通过把eTOM划分成多级层面,使框架应用者可以参照eTOM不同的框架层面来安排其企业框架或流程实施,比如,根据第一级和第二级层面或根据第一、二、三级层面来安排。

eTOM是按以下方式来进行层次结构分解的:第0级层面——企业总体视图(也就是,eTOM的全部);第一级层面——每一纵向流程群组(端到端)、每一横向流程群组(功能);第二级层面——所有的流程元素,如,订单处理(它既出现在端到端流程群组中也在功能流程群组出现);第二级层面的流程元素可以分解成第三级层面的流程元素;第三级层面的流程元素可以分解成第四级层面的流程元素;在eTOM中所有流程分解的子层面只到第四级层面,因为流程分解不必解释从一个流程分解到另一个流程分解的同一层面的细节。分解所需的层次数量必须与流程的复杂性和所在层面的流程流向一起考虑才能有意义。

纵向流程(端到端流程)
纵向流程群组,代表端到端的业务流程视图,

横向流程(功能流程)
横向流程群组,代表与业务功能流程有关的功能视图

4、SID共享信息模型

    NGOSS提供了一整套的方法论来指导OSS/BSS的设计与建立,它的核心设计思想是利用“流程驱动”,系统设计时首先从流程分析开始,分析自己企业的核心业务流程;然后通过分析流程,提炼出所有关键的数据,利用共享信息模型将数据进行抽象,划分为不同的管理域建立共享的数据模型;最后根据共享的数据模型组建实际的OSS/BSS系统。数据是OSS/BSS设计中最重要的特性,成功建立OSS/BSS系统关键是有一个好的共享信息模型。因此,NGOSS提供出了共享信息模型的通用框架—SID。

    SID是NGOSS提出的建立共享信息模型的通用框架,SID分别从商业和系统两个视点描述了共享信息模型。一方面,SID从商业视点出发,以ETOM LEVEL 0定义的业务处理模型为基础,依据对商业过程中涉及的各种商业信息的抽象和分析,定义了各种可聚和的商业实体ABE以及各种商业实体BE,并将它们划分为不同的管理域,形成了系统和信息图SIM,从而最大限度地实现信息和数据的共享。另一方面,SID从组建OSS系统的视点出发,对各种商业实体的属性进行定义,并利用UML将它们有机地组合在一起,形成UML模型,从而为设计用于实现OSS系统实际使用的共享数据模型提供参考模型。综上所述,SID是商业和系统的实体定义和UML模型的有组织的集合。

clip_image002[6]

  • 客户域

    客户域指一个已获得或可能获得第三方支付提供商所提供的产品和服务,并具有承担法律责任能力的个人或者组织的客户信息及相关用户信息。用户信息包括用户识别信息、订购的产品信息、资源占用信息、用户评价信息。

    客户域包括:客户、用户。

  • 合作伙伴域

    合作伙伴域是指在第三方支付提供商业务活动中与支付提供商拥有共同的目标和利益并承担相应职责的组织的信息。根据合作性质可以分为:设备供应商、服务提供商、虚拟运营商等。

    合作伙伴域主要包括:合作伙伴信息等。

  • 市场营销域

    市场营销域是指第三方支付提供商进行营销和销售活动等方面的信息聚焦。

    市场营销域包括:营销方案、市场细分、竞争对手、营销活动、商机信息、报价/解决方案等实体信息。

  • 客户交互域

    客户交互域是指客户交互过程事件可能产生的多种数据信息聚集。

    客户交互域包括:客户接触数据、客户订单、客户服务请求,以及缴费/退费信息。

  • 产品域

    产品域是指第三方支付提供商如何面向市场组织产品提供及如何定义产品的信息聚焦。产品域实体定义了能够被客户购买/租赁的内容,其中包括产品、服务和资费,以及关于产品/服务的所有相关信息,包括品牌管理、产品目录、产品之间的关系、产品限制等。

    产品域包括:产品目录、产品、服务、资费等实体信息。

  • 帐务域

    帐务域(含计费)是指客户使用第三方支付提供商产品发生的清单、费用合计、优惠和收费销帐全过程信息及帐户余额管理所需的信息资料,是费用合帐、帐单生成、资金回收、欠费管理、帐户余额管理的基础。同时还包含合作伙伴及运营商的结算信息。

    帐务域包括:帐户、帐本、收支记录、帐目、帐单、清单、付费计划、帐务关系等实体信息。

  • 资源域

    资源域是指第三方支付提供商有形或无形的业务运营资源定义、开发和操作全过程的信息聚焦。资源域可以将资源关联到产品和服务,确保资源能够支持第三方支付提供商的服务交付。

    资源域包括:资源配置、资源使用、资源故障等实体信息。

  • 通用域

    通用域是跨越两个或更多主体域的业务实体信息的聚集。这些业务实体信息不是由任何一个主题域所单独拥有。

    通用域包括:协议、地域、组织、人员、知识、任务、工单等信息实体。

 

5、电子商务系统建设的实践

    以SANRR方法论为指导,已etom的分层模型来指导业务建模和产品生命周期管理过程,采用NGOSS的架构视角(4+1视图)来描述系统架构,建立其电子商务系统的SID(共享信息模型)。

5、参考资料

http://blog.csdn.net/quanhuang413/archive/2006/07/30/1001694.aspx

http://www-128.ibm.com/developerworks/cn/rational/r-4p1-view/

http://industry.ccidnet.com/art/71/20031229/78063_1.html

http://www.ccidcom.com/Technology/Support/200408/184.html

TMForum GB927_20041124_v13

Technorati 标签: ,,,,,
Tagged with: , , , , ,