第5章 法：完整的设计方法
1、3个构建前提
1.1 统一的数据思维
1.1.1 数据认知
判断企业对自身数据是否清楚统一的认知，主要看它能否回答以下三个问题并形成统一答案：
- 数据在哪？
- 数据价值在哪？
- 数据怎么用？
1.1.2 数据架构
DT时代，数据架构是用来保障数据流通畅，使数据资源运转为数据资产并作用于业务、产品商业价值的生命线。
- 业务数据化：在数据架构中，最底层是各业务系统通过业务流程或有目标的数据留存所产生的信息系统数据。利用采集、交换等方面的工具，技术人员可将业务系统中数据进行清洗、交换、汇总，形成企业的数据中心。
- 数据资产化：在数据中心中，数据开发人员可利用离线、实时、算法开发等不同的计算引擎工具对数据进行多种类型加工：将原始数据梳理、加工成可供业务理解、查看、使用的数据资产并存在于资产管理工具中，之后不断治理优化。
- 资产服务化：在资产中心中，经过标准化组织和梳理的数据资产经筛选后被灌入服务组件工具中。在服务中心中，可对所有数据的调用、运行等情况进行计量、全局监控和调度配置。
- 服务业务化：创建好的数据服务（API）可直接对接现有的业务系统或封装层交互界面的数据应用产品，最终支撑业务解决问题或提升业务执行效率，产生商业价值。
1.1.3 执行保障
执行保障指从企业的各个层级出发需要做好相应的数据战略保障和响应工作：
- 领导层必须给出数据战略的方向指引，并调整组织架构以进行相应的组织支撑；
- 管理层需要将数据战略转化为战术保障，制定以数据为导向的具体作战计划和考核指标，引导数据战略的有效细化和向下传递；
- 执行层需要根据作战计划和考核指标，积极努力地保障数据流的平稳推进、数据架构环节的有序衔接，并通过数据思维、数据知识的学习不断提高操作、使用数据的能力和边界。
1.1.4 价值驱动
数据资产价值的实现为最根本目标。要打通哪些数据，构建哪些数据资产，如何治理优化，构建怎样的数据架构，配套哪些支撑，都需要从价值出发去思考。
1.1.5 场景能力
面对不确定的未来，企业需要一种柔性的数据支撑能力：数据项之间、数据项和数据服务之间是松耦合的、能随时拆分，也能随时组合。具有复用价值的数据资产项和数据服务能力可以提前沉淀在数据中台中。
1.2 充分的前期调研
1.2.1 业务场景调研
待服务的客户是谁？客户的业务流程是如何开展的？客户日常的工作流程是如何开展的？与其相关的上游节点是什么？下游节点是什么？客户当前的职责目标是什么？团队目标是什么？部门目标是什么？
1.2.2 需求痛点调研
哪个业务环节上存在哪些痛点？这些痛点法伤的原因是什么？这些痛点的严重程度如何，会产生如何严重的后果？因此产生了怎样的需求？
1.2.3 数据摸底调研
- 不要让用户去假设有什么样的数据，而是实事求是，确实存在哪些数据就登记梳理哪些数据。
- 不要让客户小看自己的数据。
1.3 正确地落地思路
1.3.1 根据业务流程梳理数据类目体系
对企业现有业务流程的信息化系统中，可以梳理出企业现有数据情况，进而构建出该企业的数据类目体系。它由按“流程”组织的数据、按“物”组织的数据、按“人”组织的数据组成。
1.3.2 根据业务需求设计标签类目体系
对企业现有数据记性完整梳理后，可根据业务需求来设计标签类目体系。按“人/物”设计的标签一方面需要考虑业务的需求，另一方面也要基于按“人/物“组织的数据基础。
2、6个设计步骤
2.1 识别对象
"人"是会主动发起行为的主体；“物”是行为中的被施与对象；“关系”指人和物、人和人、物和物等在某时某刻发生的某种连接，包括行为关系、归属关系、思维关系等各种强、弱关系。
2.2 同一对象数据打通
由于同一个对象在多处系统留存有按不同ID组织的信息记录，因此需要进行多种ID间的同一对象识别打通。
2.2.1 ID-Mapping技术
大数据领域的ID-Mapping技术就是用来解决某一对象多源数据打通问题的。输入两两ID关系对，采用机器学习算法进行概率匹配计算，构建ID关系网络。
2.2.2 One-ID
各网站可以为用户定制一个统一ID，简称One-ID。每个用户账号ID都可以唯一对应一个具体的One-ID编码。
2.2.3 4种级别ID
- 第一级别ID：强身份属性ID，例如身份证信息、护照编号、驾驶证编号、人脸ID、指纹ID、虹膜ID等，是真实社会中用来唯一标识个体的编号。
- 第二级别ID：设备相关的ID，例如手机号、收集IMEI、收集IDFA、手机MAC、PC MAC等，它们和个体密切相关。
- 第三级别ID：注册账号相关的ID，例如支付宝账号、淘宝账号、微信账号、水表账号、医保账号、游戏账号等。它们常常体现个体的社会化行为。
- 第四级别ID：临时记录相关的ID，例如Cookie、IP地址、GPS定位、操作行为等，这类ID是一种弱ID，当没有更高级别ID可用时，也可用它们来与核心ID建立临时关系。
2.2.4 ID与ID间的关联运算
设置One-ID的床架规则后，将One-ID与其他ID进行信息打通。随着One-ID连接的关联ID越来越多，ID之间的两两组合关系对数量会增长越来越快。
2.3 数据化的事物表达
将现实世界进行快读的数据映射：将所有事物映射为“人”、“物”、“关系”三类，系统性地向下梳理各对象全维度属性，各属性下游具体属性值。数据化事物表达的意义包括如下：
- 这种方式是构建数据类目体系、标签类目体系的基础；
- 这种方式能帮助业务人员进行数据思维的转变，学会用数据语言表达、转化业务痛点问题；
- 通过这种数据化的拆解方式，可将数据信息清洗而有条理地梳理出来；
- 这种方式不仅能解决当前业务问题，也可以触发将来数据使用的灵感。
2.4 构建数据类目体系
2.4.1 数据类目体系的对象抽象
企业信息化建设通过采、存、通等步骤沉淀各项原始数据。常规企业通常只按照“业务流程”来存储数据，有一定信息化基础或已完成数仓建设的企业，可能会专门将“人”“物”相关的信息从业务系统的数据库中抽取出来，并结合“人”“物”的基本信息表，建立对“人”“物”的专有数据库，实现对实体对象的全面信息汇总。
2.4.2 数据类目体系的类目梳理
对象目录确定后，需要进行对象下数据类目的展开。
1）梳理“流程”对象的数据类目
流程类的数据类目往往可按照业务归属、业务存储库、业务表等对数据进行分类。
2）梳理“人”、“物”等实体对象的类目
数据类目体系反映了构建者对企业原始数据的理解，现实中数据库、数据表、数据字段是如何组织的，就相应转换为数据类目，不需要过于发散。
当将原始数据按照数据类目体系进行规整处理后，不管前段业务对数据采集的形式、周期、传输方式等做出何种改变，数据传递到数据类目体系后都是稳定不变的。原始数据的管理即数据类目体系不会随着业务形式、经营活动方案等上层变化而发生底层结构改动。
2.5 构建标签类目体系
梳理完企业原始积累的数据类目体系后，需要根据业务场景需要，设计标签及标签类目体系。标签类目体系的设计过程比数据类目体系更为复杂。
2.5.1 什么是标签
数据类目体系中的数据指企业原始数据，尚未加工，是所有待清洗、可加工的数据范畴。它面向数据采集端，解答的是“数据在哪里”的问题。而“标签”则是指从原始数据清洗加工而来，能够为业务所用并产生价值的数据资源，一般都需要结构化到字段粒度，保障服务化使用。它面向数据应用端，解答的是“数据怎么用”、“数据的价值是什么”的问题。
1）标签设计的两大前提
标签不能凭空设计，必须考虑标签开发落地的数据可行性；同时标签必须是业务上需要的，能够帮助业务人员做出业务判断、支撑、帮助的数据项。
2）标签和标签值的区别
标签是对某一对象的属性刻画，是结构化到字段粒度的数据资源。标签刻画某类对象的本质；而标签值是相，经常会随着时空变化而变化，每个人拥有的标签值各不相同。
2.5.2 标签设计的5种思路
标签的设计一般来自业务诉求的梳理抽象。将业务痛点拆解成对应的数据方案，将数据方案中的数据资源拆解到字段粒度，就是标签的设计过程。
- 从核心词属性角度发散；
- 从包含、拥有角度发散；
- 从详细内容角度思考；
- 从发展过程角度思考；
- 有一种特别的标签设计思路来自对相同类型事物的统一抽象。如果需要突出类型，也可以将取值转化为标签：为标签各取值加上“是否”前缀或“程度/指数”后缀。
2.5.3 为什么需要标签类目体系
按照数据映射原理可预估，企业或企业业务线沉淀下来的数据项、业务需要使用的标签项将会非常多。需要一种分类机制来对标签进行系统分类。
- 建立标签类目体系对标签进行分类管理、治理优化、规划推进；
- 可采用标签类目体系方式，从对象、类目出发设计标签。系统性思考、规划数据资产的分类分级，从上而下、从粗到细组织生产标签。
2.5.4 标签类目体系的构成
1）根目录
构建标签类目体系首先需要确定根目录。显示中细分群体映射到标签类目体系中，到底是细分根目录，还是不必细分，通过属性取值进行区分。
- 细分对象的属性是不是很不一样？当企业信息化建设越来越完整丰富，对对象的研究越来越深入地时候，需要构建非常多的对象和基于某个对象的标签类目体系。
- 不要直接将现实世界里的分类作为类目。如果细分对象的属性类型不相似，就直接拆分为多个细分对象；如果属性轮廓相似，就是一个对象。标签类目体系中的类目是对标签的分类，而不是对对象的分类。
2）对象的属性标签
“人”“物”实体对象天然具有一些静态标签。当“人”或“物”动起来，发生某种连接时，就会产生一个“XX关系”新对象。这个新对象天然带有关系发生的动态标签。这些“关系”对象的动态标签可投影到“人”或“物”身上，使其也产生相应的动态标签，eg：浏览时长、浏览渠道、浏览深度等动态标签。
3）类目体系
类目体系指的是对某一类item的分类、架构组织方法。类目体系是一种树状结构，从根目录上长出的第一级分支成为一级类目。从第一级分支中长出的第一二分支成为二级类目，从第二级分支中长出的第三级分支成为三级类目······。没有上一级类目的类目成为一级类目，没有下一级分类的类目成为叶子类目，挂在叶子类目上的具体叶子就是标签。有下级类目的类目是下级类目的父类目，有上级类目的类目是上级类目的子类目。
2.5.5 标签类目体系的类目设计思路
数据类目体系建议按照数据采集、存储、管理等系统原有体系进行划分，这样可以帮助数据管理者、数据开发者以他们的思维认知方式去匹配类目，找到所需数据。而标签类目体系则建议按照对象理解、价值场景等数据应用的角度进行划分，因为标签类目体系的意义是供业务人员、产品经理等数据资产使用者理解、查找、探索业务上所需标签，发挥数据资产价值。必须转变传统技术视角，以业务人员能理解的业务视角来组织标签。
不存在一套通用的、统一的标签类目体系结构能满足所有企业、机构、政府的各种业务、管理场景中的数据需求。不变的只有按照真实业务、管理需求来构建标签类目体系的思路方法。提供以下几点思路和经验可供参考。
1）“人”的标签类目设计思路
构建人的标签类目体系时，一级类目可从以下纬度考虑：首先较为静态、固定的基本属性，包括人的统计学信息、档案信息、生理信息、教育信息、工作信息、常住地信息等；在基本属性之上，考虑较为动态的、场景化的行为关系，包括人的各块行为内容、在行为中发生的关系；在行为之上，看看基于行为关系提炼出的兴趣习惯，包括兴趣爱好、行为习惯等；在兴趣习惯在往上，可再深度挖掘出人的性格特征；基于性格之上，可再抽象人的思维意识。
2）“物”的标签类目设计思路
构建物的标签类目时，一级类目可从以下纬度考虑：
- 考虑静态、固定的基本属性，包括物的基本信息、品类归属、颜色图案、包装存储、尺码重量、成分组成等；
- 在基本信息之上，考虑物的功能效用，包括物的功能作用、包含服务、使用方法、效用周期等。
- 在功能效用之后，更多考虑主从属性，包括从属关系、生成制造、经营销售、发布维护等。
- 在前几类静态信息之后，考虑较为动态的被动关系，包括物被使用过程中的各种关系，可以从被浏览、被收藏、被购买、被运输、被评价、被投诉等流程方面扩展。
- 从关系条件、关系行为、关系结果等前后发展过程方面扩展。
- 根据各种类型的被动关系拆分，例如被家庭使用、被工作使用、被娱乐使用等。
- 汇总深度并挖掘物的价值评估，包括物的质量评估、服务评估、性价比、安全评估、适用性、扩展性、市场占比、竞争排名、认证授权等各种维度。
一级类目构建好后，可参考人的标签体系构建思路扩展二级、三级目录，再在各个叶子类目下放入标签。
3）“关系”的标签类目设计思路
构建关系的标签类目时，一级类目可从以下纬度考虑：
- 梳理该关系所涉及的关系人、关系物标签。关系对象下的关系人或关系物是对关系的属性描述，只涉及在整个关系中所表现出的人/物属性。
- 从关系的准备层面思考，包括这个关系触发的契机、机制、准备条件等；继而从关系实际发生过程层面思考，包括关系发生的时间、地点、天气、途径、渠道等时空条件，以及关系发生的参与方、参与物、步骤、频率、程度、强弱、连接等过程行为；最后可以从关系的结果层面思考，包括流程性的直接结果、各环节链路的转化、综合效果评估、拆分各因素端效果评估、优化推荐等各种纬度。
一级类目构建好后，可参考人的标签体系构建思路扩展二级、三级目录，再在各个叶子类目下放入详细标签。
4）各对象类目汇总
把人的标签类目、物的标签类目、关系的标签类目汇总后，可以得到一家企业完整的标签类目结构图。
2.5.6 标签类目体系构建中的常见问题
1）同一个事物在不同对象处都形成标签，是否信息冗余？
标签类目体系构建的核心目的是什么？是让业务人员尽可能快速找到想要的标签，并且简便快速组合使用。在标签类目体系方法论中，建议按照各自对象去构建全面的标签，使得查找和使用标签时逻辑清晰。
2）当前暂未用到，但是将来可能会用到的标签是否需要设计？
标签类目体系是基于现有数据基础、现在及将来可能的业务需求设计和规划而来，是可复用、有价值标签的全集，需要尽可能包含人、物、关系对象下的所有可用标签。标签类目体系不仅解决客户当前需求，更是为企业将来场景化的数据需求而服务，解决的是未来的问题。
3）标签类目体系的结构是否会随着业务发展而变动？
- 标签类目体系的分层分级摇号尽量考虑到未来的适用性，不建议频繁修改类目结构。因此在每次设置类目时，需要考虑到一定的延展性，并注意并列类目的颗粒度是否一致。在标签增加时，一般不用修改原有类目，而是在原有类目基础上细分子类目。
- 建议类目体系结构一般不超过三类，分级层数不宜过多。如果标签数量较多时，更好的做法将类目深度转化为类目广度，即横向分类数增多。
经标签类目体系使用场景的大量验证发现，三级分类结构，且每级分类不超过10个，即总类目树不超过1000个是比较合适的类目结构。
2.6 前后台标签类目体系
在构建完企业的完整标签类目体系后，需要将其进一步加工为前后台类目。
2.6.1 什么是前后台类目
企业后台标签类目体系：数据资产的全集，即所有需沉淀、可复用、有价值的标签池。数据资产设计师或管理员可以创建、维护后台标签类目体系，其他人员可以查看类目体系，但不能随意修改。后台标签类目体系比较稳定，是对人物、关系各类对象的本质描述及描述属性的普适分类。它与业务场景松耦合，保持对人、物、关系各类对象的全局、稳定的标签定义。
前台标签类目体系侧重于对业务场景的影响，根据业务需求来汇集所需的标签集合，并根据业务的理解对标签进行分类，以供业务系统或数据应用调用。因此前台标签类目体系会随着业务场景变化而变化，是灵活可配的。业务场景本身可能是短暂的，快速产生，快速关闭，或者演变成另一种业务场景，那么其所关联的前台标签类目也会随之新增、删除或演化。
2.6.2 前后台类目的联系与区别
前台标签类目一般按照大场景/子场景/数据服务等层级展开。在大场景/子场景/数据服务下先抽象处所涉及的对象，再去后台标签类目体系对象下的标签总集中找到该数据服务所需的标签，并添加到这个前台类目对象下。
前台类目构建的思路与后台类目不同，前台类目构建的方式往往与数据场景设计密切相关，一个设置合理的前台类目体系往往与数据产品系统设计息息相关。前台类目能方便数据产品系统的应用开发，帮助前段开发工程师快速厘清数据产品各功能模块与对象标签的映射关系。
将梳理好的前台、后台标签类目体系合并在一起，就构成了一个企业的完整标签类目体系。
2.6.3 区分前后台类目的意义
为什么要区分前台类目和后台类目？因为业务需要与技术管理存在矛盾。一方面，业务是灵活的、变化的，它对数据的需求是高响应和灵活可调，因此针对某个场景的标签组织方式应该是自由可配置的。但另一方面，从技术视角管理标签时又希望标签饿组织方式是较为稳定的，且业务人员来标签门户看、选标签时，也希望标签组织方式是较为稳定的。
2.6.4 完整的前后台类目设计步骤
- 从企业现有业务需求和数据情况出发，识别出对象有哪些；
- 确定这些对象作为标签类目体系的根目录；
- 梳理各个根目录下所有可能的标签，采用类目体系结构会标签进行分类；
- 对后天目录进行记录、规划、统一管理；
- 在各个后台类目下放入具体标签；
- 后台标签类目体系构建完成，这是对企业全部标签的类目管理，形成标签类目涉及文档或可查阅的系统信息；
- 根据业务场景需要，确定某个数据应用场景，即前台；
- 确定该前台场景中所涉及的对象，原则上前台对象是后台所有对象的子集；
- 根据前台数据应用场景涉及，梳理所需标签和前台类目结构；
- 将前台类目进行记录、调整、统一管理；
- 在各个前台类目下放入需要用到的标签。
标签设计和类目设计过程是相互融合的互补过程：可以选择先根据业务需求设计标签，再对标签进行类目划分；也可以先规划类目，再在类目下设计具体标签；实际情况也可能是以上两个过程的反复优化迭代。