【IT168 专稿】
摘要
一个企业会有多个市场战略，每个市场战略都会有自己不同的目标客户群，而在每类客户群中，有些时候也会有自己一些独特的客户，需要用有针对性的站点来满足他们的要求。而甚至有些跨国企业要在不同的国家用不同的语言，形成不同的产品展示目录，在这种前提下，如何有效的管理这些业务资产（business asset）并最大程度在这些不同的站点之间去重用数据，并降低整体的运维成本成为这类企业电子商务战略的最大挑战。本问将介绍跨国公司如何有针对性的建设电子商务站点，总部构建、分站点自行维护的解决方案。
在一个复杂的商业环境下，一个企业通常需要多个战略来满足客户对公司产品的不同要求，具体来看一些例子，比如有些市场战略需要根据不同的区域定制不同的站点，或者是根据同一集团下的不同品牌开发独立的站点，又或者是不同的语言。在这样情况下要在运维层面上获得成功，这些管理大型站点的可测性和扩展性就边的非常重要。当这些方面要在每个分站体现自己的独自特点，如页面展现、市场活动，目录这些必须在分站层面上进行维护，因此将这些方面与总部建站共享同一基础数据。实际上，从我们的经验来看，一般75%-90%的配置数据在不同的定制站点里都是一样的，而其余部分才是由于一些市场原因才创建的个性化数据。
在这篇文章中，我们将介绍WebSphere Commerce这个电子商务套件，关于如何用扩展站点技术（Extended Sites）解决多站点企业的电子商务扩展性难题。通过扩展站点技术（E-site），企业可以创建并管理一组通用的公共数据集，这些数据，我们可以将在所有的站点中复用。根据这些数据，我们可以快速创建出“扩展”的站点，并辅之以必要的定制来将满足新站点的一些个性化的需要，如市场活动，颜色等等。
我们首先介绍扩展站点技术所适用的一些通用的业务场景，并分析需要用什么样的技术来让这些站点能够共享信息资产，从而从为大型企业降低管理成本的角度用技术手段去实现它。
二、扩展站点业务模型与典型应用场景
如我们在前面介绍所说的，为了成功，一个企业需要根据不同的市场策略去展现不同的企业形象，这些如同一张张不同的“脸”让企业的客户看起来象不同的站点，使这个站点能够适合一些独特的市场分额的个性化要求。
在本文里，我们主要讨论2个业务模式：B2C模式和B2B模式。在B2C模式里，一个企业在线销售产品和服务给大众，在一些特定的业务形式下，这些顾客会有一些限制，比如消费者是某个公司的员工，这样就可以使这个公司的员工购买行为更加普遍。
B2B的业务模式，一个企业与另外一个企业通过网上实现业务，这里包括对终端企业客户以及一些产品的分销商等。
当然，所有企业的市场战略都是唯一的，不同的销售机构创建自己独特的方式来影响顾客。本文里，我们在B2C和B2B描述几个相同的场景，并创建和管理这些扩展站点。这些场景归结起来包括在跨国家（区域），跨品牌，多市场策略之间和某些大型客户之间创建这样的可“扩展”的站点。
1、在不同的国家的多站点建设
通常，一个销售型企业需要在不同的国家或者区域里维护一个产品的展现与销售，那么一个跨国型企业，销售策略需要国界（洲）的制度和权限，以及不同的市场策略和销售区域制约。如果，当跨国企业总部维护着一个单一的产品和服务，而不同的国家和区域将决定哪些产品是需要展现在他们的站点里。这些可销售的产品之间的差异在于不同国家的贸易规定和生产制造过程以及市场战略的影响。
市场活动需要针对不同的国家（区域）来实行，通过特定的广告与促销可以让不同的市场活动执行的更加有针对性。不过，有的时候也需要执行一个统一的市场战略，无论区域。
那么共享的这部分信息资产，有的时候也需要去区分一下。比如，产品的描述可以被所有卖这个产品的站点共享，但是不同的区域的站点在描述这个产品的时候，需要用不同的语言来完成。在美国，一些顾客会选择浏览用西班牙语的网站，而在加拿大，许多站点是用英文和法文共同组成的。一个跨国的销售站点需要建立起这个机制：需要根据不同的地域来选择语言在线显示和销售产品。
当站点在不同的国家建立起来后，相应的定价就需要根据当地的货币制度。这就需要在不同的货币制度中来管理价格，并且根据制度来建立不同的购买流程。
2、跨品牌的多站点建设
根据品牌创建的站点通常只显示这个品牌的相关产品，但是在有些情况下，这类产品在不同的品牌里是有很大区别的。许多产品经常在多个品牌下被出售，但是从网站的展现层来看必须定制成为能够随不同品牌进行销售，包括不同网站外观，整体浏览流程和产品显示页面。
另外一个独特的品牌站点技术是通过站点来将市场策略信息带给客户。当有些企业有多个品牌的时候，每个品牌有自己独特的市场策略和促销活动，如产品的向上销售和交叉销售，促销和广告都可能在不同的品牌站点有所区分。
3、不同市场分类的多站点建设
通常，一个典型的电子商务销售站点也需要针对不同的市场分类进行销售，其中最典型的差别就是B2B和B2C客户通过不同的子站点来进行分类。另外，在一个B2B的分类中，还需要根据对方行业，分为教育、交通、制造业等不同的特性创建站点。这些站点都创建在一个相同的目录数据里，但是每个站点都需要过滤出子站点所需要的那部分个性化目录数据并应用到子站点来。如同跨品牌一样，市场活动和市场信息都可以通过子站点来唯一的创建，但是也同样可以从集团总部传递跨品牌，跨市场分类的整体市场营销信息。
在B2B的需求当中，每个站点要满足不同客户的不同需求，这里在中小型企业中尤其明显，因为这些企业的大量客户都分布在同一个市场分类里，不同的客户还需要有自己的站点定义，比如装运方式和支付选项，以及产品包装方式等等。在许多时候，为了能够更好的满足大多数客户的需要，一个通用的典型订单都会被提前设定好。在这样的事先安排下，一个客户也许要按照合同预先核实的一些条件来进行交易。又或者一个客户可以针对某一个特别的招标进行价格谈判等。
不同的企业用户也可能会需要独特的购物流程，比如，有些用户需要订单审批，有的却不用。可能有些客户在下单的数量上还有限制，又或者有时候一个客户甚至希望在为他们制定的站点能看到自己公司的名字。
4、针对大客户制定站点
由于大型客户有着比较特殊的购买需要，他们的需求的跨度有从特别针对的价格体系到产品购买权限，以及一些特定的市场活动和站点风格等等。比如，大型客户需要不同的结帐流程，需要独特的市场信息等等。在注册流程上，也可能不尽相同，如一些公司需要审批他们的员工注册信息，而另外一个大公司必须用分配给他们的一个公司代码或者密码来进行注册。
此外，订单通知是不同企业在另外一个方面的需求，有些公司需要得到通知每个订单的信息，有些企业需要得将每个订单按照某个合同执行，或者发给某个负责订单管理的人。因此在大型企业客户里需要进行访问控制管理。一些企业允许所有的用户都能下订单，而系统管理员可以查看该部门的所有订单。另外一种情况是所有企业客户可以浏览产品目录，但是只有采购员可以下订单。许多访问控制的方式都是可行的，主要是根据企业买方的需要。
另外一个通用需求是大客户通常需要集成他们的采购系统，所以采购订单需要自动流转到电子商务系统环境上。注册的授权用户需要有能力去跟踪自己的B2B采购定单状态。
这类业务模式改动虽然不是很大，但是需求却很普遍，这些例子都是为了阐述一个针对一些大客户站点，并根据他们的特殊要求而剪裁站点。当然这些站点都需要运行在一个统一的平台上，共享尽可能多的业务逻辑和数据，因此整个卖方组织的管理成本将得到降低。
三、业务建模
现在我们来描述一下如何根据业务进行扩展站点技术建模，以及WebSphere Commerce中用来实现这样业务模型的方法论，从而来实现这样的运行在单一基础平台上的大型定制作化站点实施。下面我们循序渐进的来分析如何进行业务建模：
1、商店
银行发生业务交易是它定义自身为一个金融服务提供商，在WebSphere Commerce里，我们将这个业务环境定义在“网上商店”，显然，既然叫作商店，那么业务模式是从零售业务模式中引导出来的，即购物者在卖方运营的商店里购买产品或者服务，最基本业务元素是商店有一个可供交互的空间，然后才能进行交易。
1.1 基本的商店建模
那么要建立WebSphere Commerce的多店业务模式，第一步就是先要决定商店所要表现的内容。安装好的WebSphere Commerce 可能只包含一个单一商店模型，如果这个商店已经能够满足业务需要。但是通常，WebSphere Commerce实例可以通过扩展站点创建出上百个，甚至上千个不同的商店，并支持不同的业务模型。
通常，建一个商店来满足有着共同的展现层需求、公共目录以及共同针对的市场营销活动。从另外一方面来说，如果一个客户，或者说一个客户集，与其他客户有着一些区别，如需要一些独特的业务逻辑，或者需要设计独特的业务数据模型，如产品目录，价格和库存，因此说明需要一个单独的商店来满足这些客户的需求。
如我们上面描述的，成功管理大型多站点实例的关键在于卖方通过管理单一IT基础架构，让整个企业组织分别去管理整个多站点的运维的能力。其中每个站点都只要选择一些所必须的业务资产进行管理，而不是单纯复制站点。例如，每个站点都需要从整个产品目录过滤出来再进行展示给终端购物者。另外，每个站点可能需要增加一些特定产品。同样，每个站点也需要能力来决定是否整体市场活动是否在自己的站点显示出来，也只在自己的站点上建立自己的区域市场营销活动。
刚才提到的这个WebSphere Commerce用来共享数据资产就称为store Path，下面这张图就是来阐述这个概念：
Figure 1 –目录共享
在这个例子中，通过扩展站点（extended sites）机制创建了针对个人客户（B2C）和企业客户（B2B）2个商店，这2个站点所销售的产品都是从主目录（Master Catalog）里过滤出来的。
为了能够共享产品目录，必须先创建一个“样本商店”。“样本商店”是不公开的站点，但是却管理维护着最全的电子商务数据。在这种情况下，样本商店拥有着catalog，而扩建出来的站点自身并不需要去创建自身的目录数据，取而带之的是用store path来指向样本商店来获得产品目录数据。这样看起来象每个商店都有自己的数据，而实际上每个站点都是从asset store继承下来的。除了目录，在其他方面，如展现层，市场活动，创建出来的商店都可以有自己的特性和共性。
1.3 混合扩展方式
刚才介绍了目录的扩展方式，那么除了目录，其他的业务资产也可以通过类似的store path方式进行扩展。WebSphere Commerce在其他业务资产上也提供了相同的机制进行共享，如下图：
Figure 2 – 展现层和目录层的扩展路径（ store paths）
在图2中，卖方需要创建2个教育行业的网店和2个政府行业的商店。这4个店都共享着相同的目录数据，但是不同行业的site有不同的展现要求，比如他们有着不同的结帐要求，页面风格上，产品显示上也有不同的需求。为了满足这样的业务要求，卖方管理员创建了一个展现层样本商店，它包含了页面（JSP）到后台的业务调用。
通过上图，我们可以看到卖方只要管理一个目录资产，而管理2个展现逻辑，分别一一对应不同的行业，从而创建出四个网上商店（2个是针对教育行业，2个是针对政府行业），而四个商店又可以分别创建自己的市场活动，配送和支付模式。
1.4 其他可以共享的扩展路径（store path）方式
到这里，我们已经分析了产品目录和展现逻辑是可以通过asset store进行共享的方式实现。其实其他的一些业务资产也可以通过这个机智来实现。比如，向上销售和交叉销售，市场活动，合同，业务规则都可以通过store path进行共享。其灵活性在于可以为不同的业务资产属性去创建一些自己的asset store，再通过store path进行建站。因此，资源就可以根据业务需要从混合的样本站点中进行继承，比如，通常一个卖方会创建一个产品目录的样本站点，这个在线站点是给所有的在线商店共享的。另外，会创建一系列展现层的的asset store，包含展现信息和营销活动。通过这种配置，很小数量的样本商店（asset store）就可以作为的模版来创建出一个大型多站点的配置。
1.5 扩展的资产共享
Store path的功能不仅仅在于共享数据资产，也具备部分数据共享的能力。回到图2，我们可以看到K-12这个商店只需要销售他维护产品目录中的一个子集，也许其中有些产品或者目录并没有应用到这个分类里。实际上，每个扩展出来的在线商店需要应用不同的过滤器，因此只有与这个过滤后出来的产品才能够出现在web上进行销售。另外，当主目录为所有的产品都定义了基本价格后，每个客户商店还可以进行自己的调整，在有的情况下还允许重置价格。
WebSphere Commerce提供了目录过滤器实现上述功能，它提供了业务规则来对每个商店规定store path，下面是具体的例子：
图3-主目录
图3显示的是通过工具来对主目录进行管理，图中有四个较高级的产品目录，下一张图显示不同的商店用不同的产品目录
图4-目录过滤器在主目录的基础上定义了2个不同商店的目录结构
图4显示了通过两个目录过滤器来创建两个常识点的产品目录。第一个商店不包括woodworking产品，另外一个店不包括drills和其相关产品。
通过上面的例子，我们可以通过单个控制后台去管理完整的产品目录，同时可以为每个商店创建供在线销售的目录子集，并可以根据需要进行价格的调整，调高或者调底，或者制定一个全新的价格。
虽然上面例子考虑的是一个简单也小的产品目录管理，但是从中反映了WebSphere Commerce提供的底层机制通过实践已经证明能够满足大量产品管理和站点扩展功能。
产品的store path允许卖方不仅仅是定义产品子集并做价格调整，还可以为扩展出来的这个商店去创建一些特定的数据。因此，举例来说，一个针对大客户定制出来的站点，包含着卖给特定这个大客户的产品目录，因为这些产品，以及其组合被放在这个商店里，其他用户则访问不到。但是这个大客户商店里则可以看到通过主目录被过滤器过滤出来的商品以及这个商店所特有的一些产品。
我们前面讲述的是一个跨国企业如何通过高度集中数据资产来扩展多个在线商店。通过这样的方式，跨国大型企业可以创建个性化的自定义商店来满足不同国家，不同地域、不同客户分类的站点，同时降低整体的管理成本。在WebSphere Commerce里，我们将这种个性定制站点技术叫做“扩展站点（Extended Sites）”。这种解决方案让许多大型企业和跨国公司的电子商务战略变的更加灵活和容易管理，并做到了针对性的客户服务，提高了客户满意率。
WebSphere Commerce能够进行数据共享和扩展的有：
- 产品目录：不同的站点需要有不同的产品目录，过滤器和后台管理可以维护商店自己的目录。
- 价格：不同的站点的价格都可以由基准价中扩展出来，并根据需要在不同的商店里增加减少一定幅度。
- 市场活动：不同的站点需要展现相同的市场活动，或者加一些特定的市场活动
- 促销：不同的站点需要共享同一类型的促销，并应用到不同的区域去。
- 业务规则：不同的站点需要共享一样的业务规则，如支付或者配送策略。
- 基本合同：不同的站点，需要给不同的B2B客户实行一定的电子合同。一部分客户的合同内容是基本一致的，可以作为样本进行扩展，比如创建政府客户，企业客户，教育客户合同等，然后根据这些创建不同的行业客户站点，再做一些价格调整等。
- 展现层：不同的站点需要共享展示，如合同样本商店一样，不同行业可能在展现层也可以继承。
- 业务逻辑：一些业务逻辑，在许多站点是可以共享的，尤其是在行业性比较强的分累里。
- 整体组织结构和访问控制策略
