评估电子商务平台的 10 大技术考虑
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
考虑 7：标准
应用程序是否基于标准的平台构建？ 您可能见过一些优秀的应用程序可解决所有类型的业务问题，但后来却发现您员工的技能并 不支持这些应用程序编码所用的语言、数据库或框架。如果采用这些应用程序并对员工进行 相应培训，则员工会因为紧紧拴在这一难懂的解决方案上而担心自己职业发展的局限性。 电子商务不再是 IT 唯恐避之不及的领域。它是企业应用系统组合中一个基本、关键的部 分。它必须运行在一个基于标准的平台之上，而此平台又要能够由组织内以及更广泛市场 中的标准技能提供支持。您要能够灵活、广泛地选择代理机构和系统集成商来从事开发。 在当今的企业应用程序中，所用技术已仅限 Java/J2EE 或 Microsoft .NET 架构。此外， Gartner 等行业分析机构也强烈建议企业在寻找电子商务应用程序时宜“买”不宜“建”。
考虑 2：产品目录
现在的目录模式能否满足未来需求？ 产品目录是您销售的每件商品的在线信息库。它必须有效地促进您最想卖出商品的销 售，同时帮助客户找到其正在寻找的商品。但结构不好的产品目录可能僵化、不灵活， 特别是在用户所要存储的产品属性与电子商务应用程序中的定义集不一致的情况下。为 使僵化的产品目录适应业务现实，企业必须不再乱用数据域、乱填不相关的数据到必填 数据域、在多个位置复制数据以及开发难懂的代码来人为提供信息，而这些信息产品目 录本身并不支持。 预测未来销售什么样的产品以及可能需要其他应用来填充目录可能较难。但您必须未雨绸 缪。僵化的应用程序和短视的业务规划可能导致灾难性的后果。企业会丧失快速调整产品 和促销以及持续适应不断变化的电子商务业务需求所需的敏捷性。
考虑 3：业务用户控制
应用程序能否直接帮助营销人员、营销经理及其他业务人员？ 许多 IT 管理者都渴望不存在要求苛刻的业务用户。他们渴望业务请求不再那么突然或那么 紧急。他们渴望业务能自己进行日常更新和编辑。许多电子商务应用程序都需要 IT 资源来 进行日常维护，更不用说重大项目了。这就导致了业务用户与电子商务网站的日常运作完 全脱离。他们将其更改请求发送给 IT，而 IT 除了给予回应别无选择。IT 难以做出规划和确 定优先级，因为他们要处理源源不断的高优先级紧急更新。 不过业务用户也想取得控制权，他们能够安全地自行完成每一项任务意味着 IT 将可以少完 成一项任务。 评估电子商务应用程序时，必须确保所选应用程序在技术、架构和功能上都没问题。但同 时要选择业务管理者可以单独使用的工具。应自问以下问题： 产品和类别管理者能否控制各自负责的目录部分？ 无需 IT 参与，销售人员能否定义产品促销和折扣、订单及发货？ 无需 IT 提取客户列表，能否发送有针对性的电子邮件营销活动？ 高管能否采用自己的标准报告，甚至是自己新建报告？ 业务用户能否直接管理不断变化的关键内容（例如主页）？ 业务用户能否自信不会“中断”网站地完成所有这些活动？
3
评估电子商务平台的 10 大技术考虑
考虑 4：搜索
客户查找所需内容的难易程度如何？我根据客户搜索推销产品的难易程度如何？ 搜索框通常是电子商务客户使用最多的工具。曾几何时用户很不看好搜索。如今，用户不 仅认为搜索能找到他们在找的产品，还能指引他们去了解那些产品。真正有利于客户的搜 索体验可以显著增加在线收入。但仅靠自己网站的搜索还不够，还需要诸如 Yahoo! 和 Google 之类的外部搜索引擎来查找产品。但动态生成的电子商务页面会给网站管理者带来 麻烦，因为搜索引擎蜘蛛程序可能会误解它们在动态生成的页面上发现的内容。正如我们 通过自己的在线体验所了解的那样，最让客户沮丧的是进行了搜索但却找不到网站上明明 已经存在的内容。 评估电子商务应用程序时，应寻找个人搜索体验卓著的业务控件。应自问以下问题： 我如何才能将电子商务搜索体验轻松融入在线商店？ 客户可以根据哪些产品属性进行搜索？ 如果客户使用与我的产品描述类似但用词不尽相同的术语进行搜索，将会怎样？如有拼写
考虑 8：集成
应用程序与其他系统相集成的难易程度如何？ 电子商务网站以前曾是孤岛，现在是一个高度集成的应用，涉及到许多其他系统和流程。 其开发和支持团队由技术和业务专业人员组成，并推动企业战略的一个重要部分。随着企 业 Web 渠道与其他客户接触点相结合的方法不断增多，简单、易用的集成成为必需。电子 商务应用程序的每一个元素几乎都可以是独立的，也可以由其他系统驱动。 评估电子商务应用程序时，应强调模块化，它将允许用户通过自定义或调整应用程序的各 个不同方面来满足独特的业务需求。此外，通过模块化解决方案，此过程中用户也不会破 坏网站其余部分的完整性。应自问以下问题： 应用程序将客户数据存于何处？ 哪个系统拥有主产品目录？
6
评估电子商务平台的 10 大技术考虑
哪个应用程序负责当前的 SKU 库存盘点？ 哪个应用程序负责定价？ 哪个应用程序负责财务报告？ 如何传达和履行订单？出问题时会发生什么？信用卡详细信息如何授权？如何处理交易
结算？ 如何处理欺诈检测？ 促销和折扣如何与其他渠道同步？ Web 应用程序如何才能与门店系统集成以进行门店选购或退货处理？
考虑 9：互操作性
应用程序是否支持面向服务的架构？ 许多有远见的企业都希望其不同的应用程序能够“协同工作”，以便能够快速组装新的组 合应用程序和业务流程，进而提高市场竞争力。企业更好地响应不断变化的业务情况离不 开面向服务的架构 (SOA)，同时要能基于 Web 服务将应用程序连接在一起。任何这样的架 构可能都包含电子商务应用程序，其中包括电子商务应用程序存储的数据（如客户、产品 和定价信息）及其支持的业务流程（例如订单下达和库存更新）。 评估电子商务应用程序时，应寻找灵活的企业架构，并仔细考虑应用程序如何与其他系统 互操作。应自问以下问题： 应用程序能否支持企业对企业 (B2B) 和企业对企业对消费者 (B2B2C) 业务流程？ 应用程序能否支持购物之外的其他交互，如 Web 自助服务或客户服务？ 电子商务应用程序中的哪些信息是通过 Web 服务提供的？应用程序如何完成此操作？ 哪些业务流程作为 Web 服务提供，从而使其他应用程序能够轻松地调用它们？ 应用程序如何才能连接到我的企业 SOA，以便实时了解企业内其他地方发生的重要业务
1
评估电子商务平台的 10 大技术考虑
考虑 1wenku.baidu.com可伸缩性
流量处于高峰和低谷时网站能否高效运行？ 在 IT 营销中，可伸缩性 可能是最滥用的术语之一。软件制造商会让您相信，编写的任何应 用程序都力求从一开始就具有可伸缩性。但如果任何应用程序都必须可伸缩，则它肯定是 一个主要电子商务网站。反应缓慢的内部应用程序会令人烦恼，而面向客户的应用程序如 果反应迟钝，就会让客户感到沮丧，会将他们推向竞争对手，从而扼杀您的在线业务。 电子商务网站的好坏取决于其对高峰流量的处理能力。随着网站人气的上升，其扩展需要 尽量减少工作量，以避免基础架构管理成本过快上涨。 评估电子商务应用程序时，应参考规模和概况类似的企业。应自问以下问题： 网站支持的高峰访问量（或打开的会话数）是多少？ 网站每天收到多少订单？ 每位访客每次访问的平均页面浏览量是多少？ 产品目录的大小或复杂程度如何？其中包含多少个类别、产品和单品 (SKU)？ 主页和主要的详细信息页面的平均响应时间是多少？ 需要多少硬件、软件和基础架构来处理这些数量？
考虑 6：报告和分析
我有了解在线业务所需的所有特性吗？ 电子商务网站存储着有关客户及其行为和偏好的重要信息。但对于如何利用这些数据所蕴 含的业务价值，企业通常束手无策。对网站进行适当配置以捕获和记录所有可用信息可能 并非易事，特别是在数据源种类很多时。此外，随着时间的推移，用户可能还会以不同的 方式使用数据，并且可能需要新的信息以驱动特定的营销活动。或者，用户可能需要根据 所跟踪的其他行为来开展营销活动。 评估电子商务应用程序时，应记住您无法控制您无法衡量的东西。深入了解在线商店的运 行情况对于持续成功至关重要。应自问以下问题： 网站如何捕获和存储历史数据及行为数据？ 我可以从客户搜索中获得哪些启示？
5
评估电子商务平台的 10 大技术考虑
哪些预集成的工具从这些数据中提取业务智能？ 哪些报告和信息板揭示我的业务情况？ 监视转化率和平均订货量等业务指标的难易程度如何？ 我能否通过报告进一步深入了解结果背后的数据？ 通过创建即席报告来快速获得特定问题答案的难易程度如何？ 我能否将 Web 数据与非 Web 数据合并提供多渠道的业务视图？
Oracle 白皮书 2011 年 3 月
评估电子商务平台的 10 大技术考虑
评估电子商务平台的 10 大技术考虑
引言
随着越来越多企业的电子商务网站作为重要的收入驱动因素而日益盛行，大型零售商现在都将 其在线商店视为关键业务。当许多电子商务零售商更多地关注在线渠道时，他们都发现当前的 电子商务平台无法再支撑其不断增长或发展的业务需求。电子商务高管及其 IT 高管开始寻求更 先进的电子商务应用来最好地满足其当前和未来需求。 选择长期的和正确的电子商务应用是一个困难的工作。依据当前需求以及一组尚无规划、不明 确和不确定的未来需求来制定决策并不容易。此外，电子商务网站功能乍看好像非常简单，几 乎商业化：所有电子商务网站都有类似功能如产品目录、商品的搜索和导航、购物车、提供促 销像免费送货等以及安全交易。 但这些常见、预期的功能掩饰了一些复杂的能力，而这些能力能使网上商店保持最佳的吸引 力、快速响应以及高交易量下的良好运行。电子商务应用的能力差异可以导致电子商务网站成 功或失败。 本白皮书提供 10 个考虑因素来帮助您选择下一代的电子商务平台（应该是您需要购买的最后一 个电子商务平台）。
错误会怎样？ 我能否根据客户的搜索来了解他们？ 搜索引擎是预集成并且可感知目录的吗？ 客户搜索我的网站时我能否展示相关促销？ 创建筛选和导航路径时我有什么业务控件？ 外部搜索蜘蛛程序对我的动态网站编制索引的难易程度如何？
考虑 5：敏捷性
我利用业务请求来监视和响应单个 Web 访客之行为的难易程度如何？ 试想一下这种情况并看看效果：某电子产品在线零售商的营销团队要在未来两周内进行高 清晰度电视 (HDTV) 促销。对于查看五款以上 HDTV 的每位 Web 访客，如果该团队有其电 子邮件地址，该团队就要发送促销电子邮件。 IT：听起来可通过少许编码来实现。 营销：又有了新的想法 — 我们要向在两周内（而不是在一个会话中）查看五款 HDTV 的任 何人发送电子邮件。
4
评估电子商务平台的 10 大技术考虑
IT：有点棘手。我们需要存储和增加一个值，这意味着数据库模式的更改。 营销：如果客户看了十款 HDTV，我们也不希望客户收到多封电子邮件。 IT：对于为期两周的促销而言，工作量将相当大。恐怕能否在两周内完成更改和测试都很 难说。 营销：我们想要一份结果报告。 IT：您在开玩笑吧！ 此情此景普遍存在于在线业务中。令 IT 沮丧的是，营销人员并未意识到其请求实现起来有 多难，特别是时间要求得还这么紧。但此类业务需求恰好是电子商务平台必须支持的。理 想情况下，电子商务应用程序无需任何页面、代码或数据库更改就应实现这些请求。管理 人员只需介绍一下需要监视什么以及应用程序发现符合标准的活动时应发生的情况。此后 就全交给应用程序来处理。 评估电子商务应用程序时，应寻找一种能监视客户在网站上的活动，然后根据识别出的行 为执行操作的解决方案。应自问以下问题： 哪些网站行为容易监视？ 是监视单一 Web 访问，还是监视多个会话？ 一旦发现预期行为，可以执行哪些自动操作？ 如何管理业务规则和营销方案？ 最重要的是，实施这些活动需要多长时间和多少资源？它们能否重用？
2
评估电子商务平台的 10 大技术考虑
评估电子商务应用程序时，应了解产品目录的实际灵活程度。应自问以下问题： 目录能否通过不同属性来表示不同类型的产品？有哪些限制？ 目录能支持多少个产品类别和子类别？ 单个产品或子类别能否存在于多个类别中同时无需数据复制？ 能否为企业对消费者 (B2C) 商店之外的用途定义不同目录？ 创建关联商品和打包销售的难易程度如何？
应用程序是否基于标准的平台构建？ 您可能见过一些优秀的应用程序可解决所有类型的业务问题，但后来却发现您员工的技能并 不支持这些应用程序编码所用的语言、数据库或框架。如果采用这些应用程序并对员工进行 相应培训，则员工会因为紧紧拴在这一难懂的解决方案上而担心自己职业发展的局限性。 电子商务不再是 IT 唯恐避之不及的领域。它是企业应用系统组合中一个基本、关键的部 分。它必须运行在一个基于标准的平台之上，而此平台又要能够由组织内以及更广泛市场 中的标准技能提供支持。您要能够灵活、广泛地选择代理机构和系统集成商来从事开发。 在当今的企业应用程序中，所用技术已仅限 Java/J2EE 或 Microsoft .NET 架构。此外， Gartner 等行业分析机构也强烈建议企业在寻找电子商务应用程序时宜“买”不宜“建”。
考虑 2：产品目录
现在的目录模式能否满足未来需求？ 产品目录是您销售的每件商品的在线信息库。它必须有效地促进您最想卖出商品的销 售，同时帮助客户找到其正在寻找的商品。但结构不好的产品目录可能僵化、不灵活， 特别是在用户所要存储的产品属性与电子商务应用程序中的定义集不一致的情况下。为 使僵化的产品目录适应业务现实，企业必须不再乱用数据域、乱填不相关的数据到必填 数据域、在多个位置复制数据以及开发难懂的代码来人为提供信息，而这些信息产品目 录本身并不支持。 预测未来销售什么样的产品以及可能需要其他应用来填充目录可能较难。但您必须未雨绸 缪。僵化的应用程序和短视的业务规划可能导致灾难性的后果。企业会丧失快速调整产品 和促销以及持续适应不断变化的电子商务业务需求所需的敏捷性。
考虑 3：业务用户控制
应用程序能否直接帮助营销人员、营销经理及其他业务人员？ 许多 IT 管理者都渴望不存在要求苛刻的业务用户。他们渴望业务请求不再那么突然或那么 紧急。他们渴望业务能自己进行日常更新和编辑。许多电子商务应用程序都需要 IT 资源来 进行日常维护，更不用说重大项目了。这就导致了业务用户与电子商务网站的日常运作完 全脱离。他们将其更改请求发送给 IT，而 IT 除了给予回应别无选择。IT 难以做出规划和确 定优先级，因为他们要处理源源不断的高优先级紧急更新。 不过业务用户也想取得控制权，他们能够安全地自行完成每一项任务意味着 IT 将可以少完 成一项任务。 评估电子商务应用程序时，必须确保所选应用程序在技术、架构和功能上都没问题。但同 时要选择业务管理者可以单独使用的工具。应自问以下问题： 产品和类别管理者能否控制各自负责的目录部分？ 无需 IT 参与，销售人员能否定义产品促销和折扣、订单及发货？ 无需 IT 提取客户列表，能否发送有针对性的电子邮件营销活动？ 高管能否采用自己的标准报告，甚至是自己新建报告？ 业务用户能否直接管理不断变化的关键内容（例如主页）？ 业务用户能否自信不会“中断”网站地完成所有这些活动？
3
评估电子商务平台的 10 大技术考虑
考虑 4：搜索
客户查找所需内容的难易程度如何？我根据客户搜索推销产品的难易程度如何？ 搜索框通常是电子商务客户使用最多的工具。曾几何时用户很不看好搜索。如今，用户不 仅认为搜索能找到他们在找的产品，还能指引他们去了解那些产品。真正有利于客户的搜 索体验可以显著增加在线收入。但仅靠自己网站的搜索还不够，还需要诸如 Yahoo! 和 Google 之类的外部搜索引擎来查找产品。但动态生成的电子商务页面会给网站管理者带来 麻烦，因为搜索引擎蜘蛛程序可能会误解它们在动态生成的页面上发现的内容。正如我们 通过自己的在线体验所了解的那样，最让客户沮丧的是进行了搜索但却找不到网站上明明 已经存在的内容。 评估电子商务应用程序时，应寻找个人搜索体验卓著的业务控件。应自问以下问题： 我如何才能将电子商务搜索体验轻松融入在线商店？ 客户可以根据哪些产品属性进行搜索？ 如果客户使用与我的产品描述类似但用词不尽相同的术语进行搜索，将会怎样？如有拼写
考虑 8：集成
应用程序与其他系统相集成的难易程度如何？ 电子商务网站以前曾是孤岛，现在是一个高度集成的应用，涉及到许多其他系统和流程。 其开发和支持团队由技术和业务专业人员组成，并推动企业战略的一个重要部分。随着企 业 Web 渠道与其他客户接触点相结合的方法不断增多，简单、易用的集成成为必需。电子 商务应用程序的每一个元素几乎都可以是独立的，也可以由其他系统驱动。 评估电子商务应用程序时，应强调模块化，它将允许用户通过自定义或调整应用程序的各 个不同方面来满足独特的业务需求。此外，通过模块化解决方案，此过程中用户也不会破 坏网站其余部分的完整性。应自问以下问题： 应用程序将客户数据存于何处？ 哪个系统拥有主产品目录？
6
评估电子商务平台的 10 大技术考虑
哪个应用程序负责当前的 SKU 库存盘点？ 哪个应用程序负责定价？ 哪个应用程序负责财务报告？ 如何传达和履行订单？出问题时会发生什么？信用卡详细信息如何授权？如何处理交易
结算？ 如何处理欺诈检测？ 促销和折扣如何与其他渠道同步？ Web 应用程序如何才能与门店系统集成以进行门店选购或退货处理？
考虑 9：互操作性
应用程序是否支持面向服务的架构？ 许多有远见的企业都希望其不同的应用程序能够“协同工作”，以便能够快速组装新的组 合应用程序和业务流程，进而提高市场竞争力。企业更好地响应不断变化的业务情况离不 开面向服务的架构 (SOA)，同时要能基于 Web 服务将应用程序连接在一起。任何这样的架 构可能都包含电子商务应用程序，其中包括电子商务应用程序存储的数据（如客户、产品 和定价信息）及其支持的业务流程（例如订单下达和库存更新）。 评估电子商务应用程序时，应寻找灵活的企业架构，并仔细考虑应用程序如何与其他系统 互操作。应自问以下问题： 应用程序能否支持企业对企业 (B2B) 和企业对企业对消费者 (B2B2C) 业务流程？ 应用程序能否支持购物之外的其他交互，如 Web 自助服务或客户服务？ 电子商务应用程序中的哪些信息是通过 Web 服务提供的？应用程序如何完成此操作？ 哪些业务流程作为 Web 服务提供，从而使其他应用程序能够轻松地调用它们？ 应用程序如何才能连接到我的企业 SOA，以便实时了解企业内其他地方发生的重要业务
1
评估电子商务平台的 10 大技术考虑
考虑 1wenku.baidu.com可伸缩性
流量处于高峰和低谷时网站能否高效运行？ 在 IT 营销中，可伸缩性 可能是最滥用的术语之一。软件制造商会让您相信，编写的任何应 用程序都力求从一开始就具有可伸缩性。但如果任何应用程序都必须可伸缩，则它肯定是 一个主要电子商务网站。反应缓慢的内部应用程序会令人烦恼，而面向客户的应用程序如 果反应迟钝，就会让客户感到沮丧，会将他们推向竞争对手，从而扼杀您的在线业务。 电子商务网站的好坏取决于其对高峰流量的处理能力。随着网站人气的上升，其扩展需要 尽量减少工作量，以避免基础架构管理成本过快上涨。 评估电子商务应用程序时，应参考规模和概况类似的企业。应自问以下问题： 网站支持的高峰访问量（或打开的会话数）是多少？ 网站每天收到多少订单？ 每位访客每次访问的平均页面浏览量是多少？ 产品目录的大小或复杂程度如何？其中包含多少个类别、产品和单品 (SKU)？ 主页和主要的详细信息页面的平均响应时间是多少？ 需要多少硬件、软件和基础架构来处理这些数量？
考虑 6：报告和分析
我有了解在线业务所需的所有特性吗？ 电子商务网站存储着有关客户及其行为和偏好的重要信息。但对于如何利用这些数据所蕴 含的业务价值，企业通常束手无策。对网站进行适当配置以捕获和记录所有可用信息可能 并非易事，特别是在数据源种类很多时。此外，随着时间的推移，用户可能还会以不同的 方式使用数据，并且可能需要新的信息以驱动特定的营销活动。或者，用户可能需要根据 所跟踪的其他行为来开展营销活动。 评估电子商务应用程序时，应记住您无法控制您无法衡量的东西。深入了解在线商店的运 行情况对于持续成功至关重要。应自问以下问题： 网站如何捕获和存储历史数据及行为数据？ 我可以从客户搜索中获得哪些启示？
5
评估电子商务平台的 10 大技术考虑
哪些预集成的工具从这些数据中提取业务智能？ 哪些报告和信息板揭示我的业务情况？ 监视转化率和平均订货量等业务指标的难易程度如何？ 我能否通过报告进一步深入了解结果背后的数据？ 通过创建即席报告来快速获得特定问题答案的难易程度如何？ 我能否将 Web 数据与非 Web 数据合并提供多渠道的业务视图？
Oracle 白皮书 2011 年 3 月
评估电子商务平台的 10 大技术考虑
评估电子商务平台的 10 大技术考虑
引言
随着越来越多企业的电子商务网站作为重要的收入驱动因素而日益盛行，大型零售商现在都将 其在线商店视为关键业务。当许多电子商务零售商更多地关注在线渠道时，他们都发现当前的 电子商务平台无法再支撑其不断增长或发展的业务需求。电子商务高管及其 IT 高管开始寻求更 先进的电子商务应用来最好地满足其当前和未来需求。 选择长期的和正确的电子商务应用是一个困难的工作。依据当前需求以及一组尚无规划、不明 确和不确定的未来需求来制定决策并不容易。此外，电子商务网站功能乍看好像非常简单，几 乎商业化：所有电子商务网站都有类似功能如产品目录、商品的搜索和导航、购物车、提供促 销像免费送货等以及安全交易。 但这些常见、预期的功能掩饰了一些复杂的能力，而这些能力能使网上商店保持最佳的吸引 力、快速响应以及高交易量下的良好运行。电子商务应用的能力差异可以导致电子商务网站成 功或失败。 本白皮书提供 10 个考虑因素来帮助您选择下一代的电子商务平台（应该是您需要购买的最后一 个电子商务平台）。
错误会怎样？ 我能否根据客户的搜索来了解他们？ 搜索引擎是预集成并且可感知目录的吗？ 客户搜索我的网站时我能否展示相关促销？ 创建筛选和导航路径时我有什么业务控件？ 外部搜索蜘蛛程序对我的动态网站编制索引的难易程度如何？
考虑 5：敏捷性
我利用业务请求来监视和响应单个 Web 访客之行为的难易程度如何？ 试想一下这种情况并看看效果：某电子产品在线零售商的营销团队要在未来两周内进行高 清晰度电视 (HDTV) 促销。对于查看五款以上 HDTV 的每位 Web 访客，如果该团队有其电 子邮件地址，该团队就要发送促销电子邮件。 IT：听起来可通过少许编码来实现。 营销：又有了新的想法 — 我们要向在两周内（而不是在一个会话中）查看五款 HDTV 的任 何人发送电子邮件。
4
评估电子商务平台的 10 大技术考虑
IT：有点棘手。我们需要存储和增加一个值，这意味着数据库模式的更改。 营销：如果客户看了十款 HDTV，我们也不希望客户收到多封电子邮件。 IT：对于为期两周的促销而言，工作量将相当大。恐怕能否在两周内完成更改和测试都很 难说。 营销：我们想要一份结果报告。 IT：您在开玩笑吧！ 此情此景普遍存在于在线业务中。令 IT 沮丧的是，营销人员并未意识到其请求实现起来有 多难，特别是时间要求得还这么紧。但此类业务需求恰好是电子商务平台必须支持的。理 想情况下，电子商务应用程序无需任何页面、代码或数据库更改就应实现这些请求。管理 人员只需介绍一下需要监视什么以及应用程序发现符合标准的活动时应发生的情况。此后 就全交给应用程序来处理。 评估电子商务应用程序时，应寻找一种能监视客户在网站上的活动，然后根据识别出的行 为执行操作的解决方案。应自问以下问题： 哪些网站行为容易监视？ 是监视单一 Web 访问，还是监视多个会话？ 一旦发现预期行为，可以执行哪些自动操作？ 如何管理业务规则和营销方案？ 最重要的是，实施这些活动需要多长时间和多少资源？它们能否重用？
2
评估电子商务平台的 10 大技术考虑
评估电子商务应用程序时，应了解产品目录的实际灵活程度。应自问以下问题： 目录能否通过不同属性来表示不同类型的产品？有哪些限制？ 目录能支持多少个产品类别和子类别？ 单个产品或子类别能否存在于多个类别中同时无需数据复制？ 能否为企业对消费者 (B2C) 商店之外的用途定义不同目录？ 创建关联商品和打包销售的难易程度如何？