BtB业务架构的方法论和那些坑

ITSS、ITIL、ISO20000区别为：性质不同、设立组织不同、目的不同。

一、性质不同

1、ITSS：ITSS是信息技术服务标准库和提供IT服务的方法论。

2、ITIL：ITIL是信息技术基础架构库。

3、ISO20000：ISO20000是信息技术服务管理体系标准。

二、设立组织不同

1、ITSS：ITSS是在工业和信息化部、国家标准化委的领导和支持下，由ITSS工作组研制。

2、ITIL：ITIL由英国中央计算机与电信局（简称CCTA）一手创建。

3、ISO20000：ISO20000是国际标准化组织设立的国际标准。

三、目的不同

1、ITSS：ITSS目的是发现IT服务过程当中出现的问题，及时进行改进，以便于提升IT服务质量。

2、ITIL：ITIL旨在满足将信息技术应用于商业领域的发展需求。

3、ISO20000：ISO20000目的是提供建立、实施、运作、监控、评审、维护和改进IT服务管理体系。

前不久，股神巴菲特成为IBM第二大股东引发业界关注。一向对高科技企业不感冒的巴菲特承认，在读过IBM的年报之后，他意识到以往关于IBM的观念可能是错误的。事实上，在过去差不多两年多的时间里，IBM的股价几乎翻了一番。IBM已经成为巴菲特的第二大重仓股，仅次于可口可乐。

巴菲特的信心与IBM对市场的承诺不无关系。IBM宣布到2015年营业利润达到每股20美元，到2015年新业务将带来200亿美元营收，软件将占到该公司总利润的约半数，通过生产力提高节约80亿美元的成本等，这些目标被称为IBM的2015华尔街路线图。

现在，一个名为“Blue Harmony”的项目正在为IBM的2015华尔街路线图的实现做出贡献。

Blue Harmony揭开面纱

IBM CEO彭明盛坚信，“当所有的东西都相连时，工作就流到能把它做得最好的地方”。这也是IBM向全球整合企业（GIE）转型的初衷。显然，全球整合企业意味着IBM将更加“敏捷”，对市场的反应更快，与客户、供应商之间的协作更好，生产率和效率更高，重复性资源消耗降低，运营成本也更低。

正在实施的Blue Harmony项目是实现全球整合企业的IT支撑。Blue Harmony实际上是IBM内部的一个IT项目，在Blue Harmony项目中，IBM既是项目需求方又是项目实施方，同时也是大部分产品及方案的提供方。整个项目通过建立一个统一的整合流程系统，改进多年来累积的多项陈旧的、非标准业务流程。

在这家拥有40多万员工、业务遍及160多个国家、年收入千亿美元的企业部署一个整合的IT项目，对岳扬来说是前所未有的。岳扬是IBM全球业务服务部交付项目总监，也可以说是项目实施方的一员。“这是有史以来SAP最大的一个项目。”他兴奋地说。作为一个复杂的企业转型与流程整合项目，Blue Harmony基于SOA架构，集合了IBM自身以及第三方的多款产品和解决方案，例如WebSphere、Tivoli、IM（Information Management），以及SAP的产品等。

虽然是一家领先的IT公司，但实际上，受制于历史的包袱，IBM已经拥有大大小小几千个业务系统，业务流程效率的提升迫在眉睫。从这一点看，IBM和一般的企业没有区别。在面对市场转型时，IBM与很多企业一样，都疲于处理陈旧的企业流程管理与快速响应市场需求之间存在的矛盾。对IBM来说，长时间以来经过不断开发或改善形成了各种独特的流程、系统及工具，全球不同分公司业务流程和规则存在差异、要遵从不同的法律要求，以及“IBM是不同的、最好的，流程的复杂性是不可避免的并是可接受的”的习惯性思维，都是IBM整合业务流程、实现业务精简、实施Blue Harmony的挑战。

比如，与以前单纯向客户销售硬件、软件或服务不同，现在很多时候IBM向客户销售的是打包的解决方案，而现在的流程就不适应这种需求了。IBM客户支持部门经理何清介绍，硬件部门在硬件设备签收后即可完成交付，而服务部门必须在工程师处理完客户需求后，进入系统确认，最终得到客户认可才能完成部分交付。因此，虽然提供给客户的是一个解决方案，但IBM内部要通过不同的流程去区别对待硬件、软件和服务，在响应速度上都有所差别。“大家都知道速度是非常关键的，我们要把精力放在销售的效率上，让内部系统更有效地支持销售，这样销售可以有更多的时间和客户沟通。”何清说。

省39亿美元，撤900个应用

Blue Harmony于2011年1月首先在中国实施了05版本，并计划于2012年7月在中国和德国同时实施10版本。Blue Harmony每个版本都有当地专门成立的蓝图、测试和开发团队提供支持，具备完整功能的模板将在德国实施10后全球正式发布。2013年，美国、巴西、英国分公司也将开始实施，其他一些国家的分公司也将于2015年陆续实施。

到目前为止，Blue Harmony已经带来了重要的精简，已取消了50多个现有应用。根据规划，在2015年全球正式上线时，将精简900个应用，为IBM带来累计约39亿美元的成本节约。

Blue Harmony目标是实现IBM三大主要业务流程的全球一体化与精简。Blue Harmony对“商机到订单”、“订单到现金”以及“财务”三大业务流程环节都进行完整的部署，通过精简业务流程中的重复应用，建立标准化运营流程，提升处理业务的敏捷力。

在“商机到订单”流程中，Blue Harmony令已有的系统内数据能够实时同步而无需人工输入，从而帮助客户支持团队获得最新数据，实现快速响应，抓住商机。Blue Harmony基于一个SAP实例整合了所有旧系统，将系统内部数据进行统一管理，实现快捷查询。

通过Blue Harmony整合流程后，“订单到现金”流程能够被快速访问，实现了系统间的优化互联。由于54%的交易能够实现自动化，取代了原有100%的交易需要人工 *** 作的状况。流程整合后，业务部门将更有精力集中在提升生产效率上，同时销售人员对业务流程的压力也会大大减轻，从而将更多的工作重心投入到客户服务领域。

统一的业务流程还帮助整合“财务”流程中的各类数据，实现所有业务数据的实时访问、即时修改，能够有效地减少重复资源的耗费，避免竞争优势的降低。例如，原来只能每周或者每天运行两次数据系统，导致需要耗费较大的工作量来纠正或者完善相关问题。标准化运营流程系统后，运营和财务系统被完全地整合进入同一平台，业务数据也即时进入财务系统，从而降低错误数据的出现概率。

在自我部署Blue Harmony的同时，IBM作为IT供应商，也将把Blue Harmony项目的经验带给客户。

记者手记

“敏捷力”让大象不仅可以跳舞

从经典的五大中间件品牌到推出行业解决方案，如今，IBM正在以六大能力重新定位IBM软件。这六大能力分别为洞察力、敏捷力、协作力、创新力、优化力和安全力。而Blue Harmony在IBM内部的实施应用，正是IBM软件满足企业“敏捷力”需求的有力证明。

在Blue Harmony这个案例中，IBM的角色不同以往，IBM不仅是以供应商和实施方的身份出现，还以用户的身份出现。而在我们采访过的企业部署IT项目案例中，像IBM这样的大型用户也是不多见的。IBM拥有40万员工，在全球160多个国家开展业务，年收入千亿美元。实施Blue Harmony这样一个跨地域的企业流程整合项目，其复杂性和难度可想而知。

在Blue Harmony项目里，IBM首先通过自身的尝试，证明“敏捷力”到底可以帮助企业做什么。敏捷力不难理解，无非是企业对内外部各种需求的快速的反应能力，IT是加速企业敏捷进程的技术驱动力。拥有敏捷力意味着企业的IT架构要在应用基础架构软件的基础之上，能够灵活、可扩展地建立、部署和管理应用及服务。

在IBM的Blue Harmony中，敏捷力的技术驱动首先是SOA。虽然，SOA是一种通用的方法论，但实施过程中有诸多学问。“SOA治理是SOA的关键成功因素，SOA治理和企业架构项目相匹配，在实践中需要用SOA / BPM来补充 ASAP / Ascendant 方法论，避免使用相互矛盾的架构框架。”IBM全球业务服务部项目交付总监岳扬说。WebSphere也是Blue Harmony帮助IBM加速敏捷进程的一项关键技术驱动力量。

对于此次以六大能力重新定位IBM软件，IBM软件集团大中华区战略及市场总监吴立东对记者说，现在的客户需求发生了很大变化，客户需要的不再是某个单一的软件产品，需要的是一种综合能力，比如敏捷力。向业界介绍Blue Harmony这一IBM内部的IT项目，就是让客户看到敏捷力帮助IBM自身向全球整合企业转型的价值。敏捷力让IBM这头大象不仅可以跳舞，而且身手敏捷。

前言

互联网应用的根本目标在于提高效率，现在市场上几乎所有的应用都有这个特点，实现这个目标是通过两个途径做到的，其一是网络协同，其二是数据智能网络协同在实现层面需要各个角色在恰当的时间点作出恰当的 *** 作，无论网络有都么智能，它在BtB 领域总是需要具体的人来作出 *** 作反馈的，所以信息流在线下线上的交互流转是我们在设计系统的时候需要充分考虑的一点，事实上简单的把需求方的线下业务搬到线上很多情况下不但不能提高效率，反而会发生负的外部效应

至于数据智能，绝大部分客户其实并不满足数据采集、数据清洗和数据分析的条件，最大程度上只能做到一些自动化统计功能

在实际业务中，我们会涉及到生态、平台这一类的说法

我自己的感受是90%以上关于上述课题的说法仅仅是扯淡而已。首先来看生态， 比如一片草原，无论面积多么辽阔如果只有一种花草它是经不了风霜的，而生态的第一个属性就是反脆弱性，反脆弱性决定了只有异质物种才能组成生态，所以滴滴体量再大始终成不了阿里

再来看平台，某些客户会说我要做某个行业的平台，我想成为某个垂直领域的阿里。平台的本质含义是去中介化或者再中介化，然而中介这个交易链路在整个贸易历史上从商品经济诞生的那一天开始就有了，中介能够给交易环节赋能，能够为商品赋予独特的价值，这是理解中介的立足点，任何只看到中介成本而没有分析中介价值的平台都是耍流氓，大幅度低估了传统供应链渠道的价值以及新模式推广的难度

1 概述

11 文档范围

侧重于站在产品经理的角度描述BtB 模式电商领域，在业务架构阶段可采用的一些方法和需要注意的细节，并会为此列出若干实例

本文档所述的BtB 包括 BtBtB 和 BtB2C 模式，也会涉及到 StBtC 模式

12 文档目标

从逻辑上完整的描述从业务映射到系统的过程

目标在于为项目实 *** 开发提炼出一套切实可行可落地的工作方法，能够绕开上述模式电商领域建设中一些坑

13 涉及到的名词

14 行文风格

有些是现在写的，比较口语化，有些是摘抄我以前写的博客的，比较书面化

2 tB 电商说明

21 用户属性

B端客户决策维度多，达成交易的最低要求高，但流程标准化，输出可靠性高；而C 端客户的决策维度少，达成交易的最低要求低，但流程不标准，输出可靠性低。这是tB和tC用户属性的核心区别

22 了解供应链

221 传统供应链的价值

正如上述用户属性说明，tB 业务用户决策的维度多，流程长，直接从终端对接终端的交易效率太低，成本太高，所以就在供应链上产生了的很多"客户-供应商"关系链条，把这些因素降维成生意与生意之间的信任关系，虽然流程变长了， 但实际决策效率却变高了。我们可以说，各种供应商实现了为整个交易链条赋能的功能

222 启示录

①对项目所处的行业，其中的全体参与者进行分类分析和研究，搞清楚哪些人在什么条件上有价值，哪些人在市场条件下没有价值。如果要替代掉供应链上的环节，当然是从最没有价值的环节入手，提供给最有话语权的用户看重价值的其他环节。分析的五个维度：

②为这个产业链提供某些原本不存在的价值，有效提升整个产业链的效率

23 tB 电商的本质

完整的tB 电商系统本质上就是一个信息化供应链，有完整的传统供应链内容， 同时也有具备电商特色的功能，比如促活拉新和内容模块等

24 tB 电商的结构

25 电商业务全流

26 业务架构原则

模块隔离，应对扩展和需求变更

27 产品成功的一个公式

好产品的价值=（新体验-旧体验）-替换成本＞0 这个公式我记得是梁宁提出来的

3 业务架构实务

31 指导思想

将业务单元高度抽象，每一个业务都划分为类和实例，利于后期修改以下将我认为需要注意的点提出来捋一次

32 前台和后台

这是个相对的概念，注意这个概念的主语更容易识别用户的真实意图

33 商品中心

331 各种关系

332 要点说明

①SKU 和 SPU

现在很多电商平台都以SPU为基本展示单位，但是在初期还是建议以SKU为基本展示单位，在视觉效果上显得商品比较丰富

②商品类目

可以大致分为前台展示类目和后台管理类目，两者之间需要对应一个松耦合关系，前台展示类目最好考虑周全一点，方便运营在做活动的时候随时调整

34 订单中心

关键是拆单的逻辑，拆单之后原订单会生成多个子订单，此时原订单和子订单的状态表述需要根据具体业务去协调

订单中心拆单的逻辑和WMS 中的分仓是紧耦合关系

35 支付中心

多数都是调用第三方支付的接口，没什么好说的，需要注意的是落实到具体的B 端公司，几乎每一个公司的财务制度都是不同的，那么怎么和客户的财务系统对接才是最大的工作量

36 调度中心

361 调度库存结构

362 库存调度说明

调度层相当于订单的分配中心，将订单转化成发货单，按照调度规则决定哪些SKU 由哪个仓库发货，发货仓的优先级设定

敲黑板，调度库存全部都是实物库存

363 库存调度的本质

解决供应链路中存在的反应速度和敏捷性的矛盾

37 库存中心

371 电商库存结构

372 库存同步

自上而下：从销售到调度再到仓库

自下而上：主要是入库问题，采购入库、退货入库、调拨入库

373 影响因素

销售订单、售后退货、预售、盘盈盘亏、仓间调拨、采购

374 设计重点：销售库存

可销售库存、锁定库存、已销售库存、活动库存、预售库存，预售的订单需要备货之后再推送到调度层

38 促销中心

促销的功能大致可以分为两大类：拉新和促活无论哪一类总结为三个字，坑很多

尤其是逆向流程，一不小心就会留下漏洞，例如在平台满额减的情况下，涉及到退货，退款的额度就是个很大的问题了

39 CMS

内容管理系统，主要目标是页面动态配置模块化、组件化、乐高化

310 采购中心

3101 采购业务活动图

  3102 我踩过的坑

①采购入库，很可能是批次入库的，那么在做库存同步的时候，自下而上库存数据推送就需要分批次了

②多数客户的货号都使用条形码，但是少数客户会有自己的货号编码规则，这样采购入库的时候就会多一道贴码的工序

311 仓储系统

包括WMS、TMS 和 OMS，主要功能是将订单转化为拣货单、发货单、入库单

等，以及分仓、分区域，并做仓位管理，生成拣货路线，根据拣货路线生成拣货波次，太复杂了，都可以写一本书，在此略过不提

312 物流中心

大部分项目都会直接对接快递100,可是要明白一点，快递信息有两个层面的含义，一是反馈实时空间位移距离，二是缓解买家在等待到货这个过程中的焦虑， 所以真正要设计一套完成的物流反馈信息还是很有难度的

313 风控中心

记录用户行为，分析规避可能产生的违法行为，比如诈骗、利用系统漏洞刷单刷钱

314 总结一下

设计整套电商系统需要遵循一个铁律：单据驱动数据

4 方法论

41 一个原则

服务于BtB 模式下的互联网产品首先是受客户的具体业务约束的，这一点有别于纯粹 2C 的产品有很大发挥空间

一般情况下在MVP版本，电子商城或者整个电商系统就是为客户的实体业务做素描，在还原度达到80%以上的基础上再求创新

本质上这是一种受约束的小范围小粒度的创新

42 两种方法

421 概念上的方法

作为BtB 领域的业务架构师，岗位职责就是完成从业务到系统的映射关系，概念上产品开发方法是这样的：

①几乎所有的互联网产品都起源于一个想法，有逼格的人把它叫做 IDEA

②尽快完成这个想法涉及到业务的闭环（MVP），包装成产品，投入市场

③全方位采集用户在使用过程中的数据，分析之后作为迭代的依据和验证标准

422 实 *** 层面的方法

①要注意一点，系统活动≤业务活动，很多业务需求考虑成本和效率并不需要在系统层面去实现

②整个过程就类似于一个反向的涟漪，从外圈向内圈蔓延，这也是一个抽丝剥茧的过程

43 实 *** 指南

431 业务调研

问怎么做的时候更要问为什么这么做，同样一个问题对于不同岗位的意义都是不一样的，360°的调研才能真正理解一个问题

提醒一点，不要迷信市调。一方面市调的样本肯定是有限的，有限的样本不一定能够反映市场的特征；第二方面，被调查的对象能够告诉你的永远都是已经发生过的事，而我们通常想做的产品都是面向今后的市场，昔日往事可以借鉴，要是用来指导将来就有的你好看了

业务调研完成后，最好输出一张服务蓝图，将客户所有与本项目有关的业务全部列出来，类似这样的东西：

432 业务分析

最好是懂技术，你会发现事半功倍，基本思路就是讲调研所得转化为系统实现，输出业务事件清单和业务用例（BUC）

业务事件清单列明了所有干系人和相邻系统与本产品之间的互动，罗列了产品需要输入和输出的各种数据流，定义了数据流的类和属性，通过数据流的类和属性计算出功能点，用来估算工作量，估算工作量的公式：

工作量（人月）=（功能点数量÷150）×功能点数量的 04 次方

433 系统分析

通过对业务用例的解读，得到产品用例（PUC），现在可以根据产品用例来建模了，这时候曾经抽象的蓝图式的产品概念开始具象化，开始向可分解的工作流靠拢

434 一张图总结

5 补充内容

51 管理需求

需求并更是再正常不过的了，在实际 *** 作中其实并没有一招制敌的方法，强行安利一种的话一般是这么干的：

①为每一个需求表明分值，表格如下

满意度从1 到 5 递增，愤怒值从 5 到 1 递减

②召集涉众为该需求评分

③分别计算出满意度平均值和愤怒值平均数

④两者相乘，乘积就是该需求的总体得分，接下来让客户自己选吧

52 客户的那些事

521 客户画像

522 客户特点

523 实 *** 影响

①通常情况下，客户指定和我方对接的负责人一般都是中层管理者，并没有最终决策权，对跨部门的业务了解程度并不深刻

②通常情况下，被指定和我方对接的负责人并不需要为项目的成败负担直接责任，权责也不是很明确

③在业务之外，还需要注意人事利益关系，这一点对项目能否顺利准时验收交付是很重要的。

④牢记一点，客户并不一定就是用户，客户需求是大于用户需求的，甚至于是冲突的，两者之间的关系分寸需要认证对待

（文/罗）

以上就是关于ITSS、ITIL、ISO20000三者的区别全部的内容，包括:ITSS、ITIL、ISO20000三者的区别、IBM在整合起到的作用【Blue,Harmony:IBM全球整合术】、BtB业务架构的方法论和那些坑等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！