4.3 理解业务
通过商业模式画布可以理解企业的商业模式，弄明白在企业的业务中谁是客户，收入从哪里来，合作伙伴是谁等。不过，商业模式画布没有将企业的内部运转结构打开，一个企业需要运转起来，需要各个部分之间的通力合作，并和用户产生交互。
业务服务蓝图
要明白的表达企业内部各方的合作情况，业务服务蓝图可以帮上忙。不过请注意在使用服务蓝图时，存在一些争议。例如，是否应该将 IT 系统参与到服务蓝图中表达？这里存在两种流派和方法：一种是使用两张图来表达，这样能看清楚企业引入 IT 系统前后的变化，区分为业务服务蓝图和应用服务蓝图；另外一种流派是将其绘制到一张图上，统称为服务蓝图。
由于在这里区分了商业模型和业务模型以及加入 IT 系统之后的形态，应用服务蓝图更多的是关注待分析的 IT 信息系统。
业务服务蓝图本质上是一种流程图，表达商业中各个参与的主体（参与业务的各个部门可以看做业务主体）之间的往来，通过多个泳道来表达参与的业务主体。服务蓝图在"服务设计"这个概念下可以看做是用户旅程的延伸。在服务蓝图中，不仅包含水平方向的客户服务过程，还包括垂直方向各个业务主体之间的合作关系，描述服务前、中、后台构成的全景图。
我找到了一份不错的服务蓝图定义和绘图模板（主要是好看），[21] 的一篇文章。
在这份模板中，服务蓝图包含 5 个主要元素：
Evidence。业务凭证或者接触点，比如在保险服务中，投保单、保单都是接触点和凭证。 Evidence。业务凭证或者接触点，比如在保险服务中，投保单、保单都是接触点和凭证。
Customer Journey /actions。用户的旅程或者行为。 Customer Journey /actions。用户的旅程或者行为。
Frontstage。服务提供方（企业）的对客部门或者单位。 Frontstage。服务提供方（企业）的对客部门或者单位。
Backstage。服务提供方的后台部门或者单位。 Backstage。服务提供方的后台部门或者单位。
Support processes。其他支持单位，比如财会、法务等。 Support processes。其他支持单位，比如财会、法务等。
这里面还有三条关键的交互线：
Line of interaction 交互线 。用户服务提供方交互的边界，可以将交付线的上下分别看成独立的业务主体，他们通过业务凭证作为客体完成业务往来，在合法的经营活动中，业务凭证会作为契约以及法律凭证。 Line of interaction 交互线 。用户服务提供方交互的边界，可以将交付线的上下分别看成独立的业务主体，他们通过业务凭证作为客体完成业务往来，在合法的经营活动中，业务凭证会作为契约以及法律凭证。
Line of visibility 可见线。用户直接接触的范围，以及可视范围。例如，用户通过某保险公司的经理人购买某保险，对用户来说用户只能看到保险经理人以及相关活动，当用户提交投保单信息后，后续的投保流程将由保险公司的具体部门审核通过，并生成正式的保单。 Line of visibility 可见线。用户直接接触的范围，以及可视范围。例如，用户通过某保险公司的经理人购买某保险，对用户来说用户只能看到保险经理人以及相关活动，当用户提交投保单信息后，后续的投保流程将由保险公司的具体部门审核通过，并生成正式的保单。
Line of internal interaction 内部交互线。内部交付线为企业内部单位作为业务主体之间的往来，这些往来关系对用户不可见，其权责本质上也属于企业对其的让渡。 Line of internal interaction 内部交互线。内部交付线为企业内部单位作为业务主体之间的往来，这些往来关系对用户不可见，其权责本质上也属于企业对其的让渡。
通过这 5 个元素和 3 条交互线我们能梳理一个企业实现其商业目标时需要参与的业务细节，并在一张图表上表达。
通过业务服务蓝图还可以发现机会点，有时候也会被体现到服务蓝图中。机会点为现有的业务蓝图中可以被改进的地方，机会点往往意味着商业机会、用户体验优化的方向。
业务服务蓝图示例
以蔬菜配送为案例，我们来看下服务蓝图的应用。我还原了一个真实的小本买卖——某批发市场的食材配送公司的业务形态。
餐厅老板往往（或者他的员工）需要自己整理一些食材清单，然后通过电话下订单给某家配送公司的客户经理，客户经理生成食材订单后，构成简易合同，随即让仓配部进行配送。好在我虚拟的这家配送公司自建了物流，出库和配送是一个部门，否则还需要新的契约来满足配货出库和物流之间的关系。
当餐厅收到货物后，食材配送公司一般会出具一张清单，餐厅清点完成后需要签字盖章。这张单据往往会被用来作为处理纠纷的关键单据，而纠纷的发生会比想象中多非常多，可以说商业就是处理纠纷的艺术。
在具有固定合作关系的商业主体之间，往往都不会结算现款，都有一定的结算周期，通过结算单来完成结算，随之进行支付，某些情况下还会出现抵扣。
和用户旅程的关系
在服务设计和设计思维中，和服务蓝图类似的思维工具还有用户旅程。不过他们之间有一点区别。用户旅程也是一种非常好的思维工具，它更加关注于用户体验，以及用户的心情曲线。
过度关注用户旅程的陷阱就是将用户和客户混淆，容易产生不计成本和盲目的用户体验优化。换句话说，用户旅程描述了某个业务主体的行为和职责，在这些行为下面我们可以绘制出心情曲线，根据心情曲线可以寻找服务或者软件产品的机会点。而服务蓝图描述的是多个业务主体之间的行为，以及职责转移，不体现心情曲线。
它们两者各有所长。在体验设计上，可以更关注用户旅程；从业务理解上，服务蓝图更加有用。有时候它们又可以相互补充，我们可以在合适的时候使用它们。
