中台之上（十五）：被忽视的产品目录

拼搏现实的明天。 2022-02-23 15:42 213阅读 0赞

产品目录大家并不陌生，无论是现已经近乎绝迹的邮寄产品目录还是超市门口经常有人发送的打折商品目录，这些都是产品目录，由于日常生活中，我们都是各种产品目录的轰炸对象，也就不能看出，它的一个作用是传递产品信息。上边的例子都是信息由企业内部向外传递，但是，很多人都忽视了它的另一个方向，就是向内传递，这方面不仅仅是意识到的人不多，能在开发中真实去应用的更少，而能形成企业级信息传导能力，通过产品目录构建起“产品信息高速公路”的，就少之又少了。

### 产品目录传导信息的逻辑 ###

上一章我们分析了通过构件模型建立轻量级架构工具的方法，通过构件与服务的关系关联起开发信息，形成架构管理依据，可以支持快速开发的需要和提升项目管理的科学性。这是构件模型向开发上的延伸，但是既然构件模型可以用于装配产品，那自然也可以向业务端延伸。在上一章的开头部分有一张构件模型的抽象结构图，左下角红色虚线框起来的部分就描述了产品目录的基本逻辑。产品目录实际上可以包含很多信息，而不像那张简图中信息那么少，可以包含设计者、管理者、销售方、合作方、产品特征、适用客户群体等各类描述信息，还可以仿照互联网产品管理方式，添加大量标签，再通过产品销售信息关联起客户，形成一个庞大的“图谱”，一张通过产品和产品目录连接起来的信息网，当这个网络具备企业级规模时，它产生的信息传导能力是惊人的。每一项产品信息都是一个产品维度，具备了高维度特征的产品信息库才具备形成产品大数据的基本条件，大数据的价值不在数据量而在维度，维度才是描述对象特征最重要的手段，而金融机构目前缺少的也恰恰是这个。

产品目录能够联通公司内外，联通业务和技术，将市场信息、客户信息、销售信息、伙伴信息等各种信息通过高维数据结构组织起来，让海量信息分门别类地流向信息需求方，成为一个高效的信息传输渠道，这才是企业级产品目录真正的价值。而当有信息无法沿着产品目录传递时，我们也可以发现是否缺少了与之对应的产品或者产品维度。如果能够按照产品目录汇集起海量、多维、完整的产品信息，就可以通过大数据和AI技术，进行更为广泛、深入的信息挖掘，产生超过单点分析的业务效果，包括产品之间的相关性、客户行为的相关性、内外部事件与产品的相关性等一系列综合分析，这是需要通过产品进行串联的分析工作。有效应用产品目录来组织信息，可以更加贴近业务对信息的理解；经过整理的产品分析信息也可以直接推送产品开发团队，完善项目效果反馈机制，提高设计人员了解市场信息的及时性。

以上介绍可以用下图表示：

![\\"image\\"][image]

### 产品维度及其作用 ###

对于产品目录而言，形成信息归集、整理和传导能力最关键的是维度，也可以换个通俗的说法，就是标签，标签的含义是使用概括性词汇或短语来描述某一内容，这些内容可以是文章、商品、视频、图片、歌曲、评论、联系人等，上图中的员工反馈、客户反馈、市场变化等也都可以被标签描述并关联到产品上。一个产品能够具有多少有效的标签，反映了产品适用范围的宽窄、承载信息能力的大小、对象描述能力的强弱。标签与分类相比，更为灵活，可以无限拓展、自由添加，可以在保持单一分类的情况下，满足各种视角的灵活展现，电商行业往往拥有海量的标签库。 可以参见以下标签应用的示例：

![\\"image\\"][image 1]

从实现上来讲，标签数据包含标签、产品、标签与产品关系三个部分，标签的产生一般包括用户打标签和系统打标签两类，前者根据用户（包括内部用户和外部用户）的需要在用户使用界面由用户添加，后者根据预设的判断规则由系统自动添加，比如点击率超过某一限定次数，则判断为热点等，目前传统行业此类应用较少，应该加大对标签的研究力度，丰富标签信息，增加标签产生和应用方式，以便更好地建设大数据能力和AI能力。

听过上边的介绍，你可能会觉得给产品贴标签、做分类是个再正常不过、也不会太难的事情，但是，在大企业中，这件事如果是部门级的，的确难度不大；如果要做企业级的，还真不太容易。多数金融企业以前还真的没做过企业级产品目录，都是部门级甚至是分行级的，各系统间的产品定义自然千差万别，所以区分什么是产品、什么不是产品、该如何分类、分类的层级有多少、每个层级怎么确定，到处都是争论，十几个大型产品条线、上万种具体产品，还不算分不清是不是产品的，确实够吵上一阵子了。标签其实是比分类更容易处理这个问题的。每一类不同的需求都可以转化成不同的标签集合，通过赋予产品大量的标签，来满足不同视角的展示和应用需要，这也就减少了部门对分类这种相对固定、又带有一定权威象征的资源的争夺。而从设计的角度来讲，基于构件模型，设计人员主要应该关注的分类就是可售产品和装配模板的映射关系，这个映射关系相当于产品的产地和配方标识，可以通过它找到产品的组成构件、构件的提供方等关键信息。这个关系如下图所示：

![\\"image\\"][image 2]

可以看出这种方式比传统的基于分类的目录结构更有扩展性和弹性，业务和技术的不同需要可以兼顾，更有助于实现本章所提倡的通过产品目录建设“产品信息高速公路”的设想。当然，标签数量过多确实不易于维护和使用，除了要不断改善技术手段外，也应当认识到，凡事有利必有弊，要获得回报也必须要有一定付出，目前的人工智能也是先有“人工”才有“智能”。

产品是一个企业的价值载体，是为客户服务的实例化表现形式，无论是生产类企业还是服务类企业都如此，产品将企业与客户紧密联系在一起，也是企业内外部信息的重要连接点，因此，应当在产品的系统化管理与实现方面多花些精力。

在此，我也聊些自己的“偏见”。现在都把“以客户为中心”挂在嘴边，似乎说产品就有些“以企业为中心”了，是从企业角度出发看问题，其实也不尽然。“以客户为中心”只是改变了看产品的视角，却并没有真正改变产品的本质——企业的服务能力，企业的服务能力自然是企业的内部问题，哪怕企业拥有的只是资源整合能力而非真实的服务提供者，哪怕你实现了多高程度的API化，所以，无论怎样强调“以客户为中心”，问题还是要回到企业、回到产品上来解决，所以，多说说产品也没什么不好。  
\\t  
**相关文章：**  
中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”  
中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？  
中台之上（三）：战略和组织结构，业务架构设计中不应被忽视的关键因素  
中台之上（四）：面对复杂的流程和数据，我们总结出了一个分析套路  
中台之上（五）：业务架构和中台的难点，都是需要反复锤炼出标准模型  
中台之上（六）：如何为一个商业银行设计业务架构？  
中台之上（七）：不神秘但很麻烦的业务架构落地过程  
中台之上（八）：企业级业务架构的实现需要不断沟通和调整  
中台之上（九）：如何基于企业级业务架构管理业务需求？  
中台之上（十）：业务架构设计“笨重”，它能跟敏捷沾边吗？  
中台之上（十一）：企业级业务架构设计的“五难”  
中台之上（十二）：如何快速设计业务架构？  
中台之上（十三）：探讨支持组装式开发的业务架构设计方法  
中台之上（十四）：尝试构建轻量级架构设计工具

**作者介绍：付晓岩**，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号：晓谈岩说。

[image]: /images/20220223/d86fd1b51e5741b6b265897421ba7147.png
[image 1]: /images/20220223/4421a4e1e88547fcac6b2d0574dfadbb.png
[image 2]: /images/20220223/6830eb85b6814d1eaabecdf7803b41c8.png