简介：针对运营商家庭业务快速增长带来的产品繁杂、推广低效问题，PPT方案面向产品运营、市场策划及一线营销人员，系统给出了家庭标准化产品库的构建方案。内容涵盖家庭产品现状梳理，宽带、互联网电视、智能硬件等自有与合作产品归类，并拆解出家庭通信、娱乐、安全、舒适、健康、智慧、生活服务七大类分场景解决方案。针对不同户型与家庭成员结构，方案设计了差异化产品组合，并配套家庭尊享套餐、欢乐包、安全包等融合营销示例，帮助团队从单品推销转向精准推荐，提升一线营销效率。压缩包内为1个PPTX文件，约341KB，重点展示了产品库的两级管理框架、常态化更新机制及分省创新产品案例（如电视购物、居家养老等），适合用于内部汇报、方案研讨或新人培训。目前已有179人学习，运营商产品经理、渠道运营及智慧家庭业务相关从业者可通过这份材料快速获取标准化产品库的核心框架与落地要点。
1. 运营商家庭业务为什么需要标准化产品库
家庭宽带、IPTV、智能家居这些业务看似简单，实际是运营商最难标准化的领域之一。各省分公司、各地市公司甚至不同营业渠道，对“千兆宽带”的理解可能完全不同：有的指下行速率，有的包含上行速率，有的还捆绑了IPTV和WiFi月租。同一个产品在线上商城叫“全家享”，在营业厅叫“千兆畅享”，到了BSS系统里又是另一个SKU，导致资费配置错乱、套餐互斥校验失效、历史订单无法解析，最终反映为客服投诉和系统二次开发的无底洞。
标准化产品库方案要解决的，就是把“产品”这件事从业务语言翻译成系统语言，用一套统一的目录结构、编码规则、属性模板和资费模型，覆盖从产品规划、定价、发布到销售、开通、计费的完整链路。这个方案的受益者不只是产品经理，还包括BSS/CRM建设者、前端商城开发、数据团队和运维——只要你的系统里出现过“一个产品多种定义”的问题，这套方法就值得对照检查。下面从领域模型开始，一层层拆开落地细节。
2. 产品库的领域模型：Product Catalog、Offer与Specification的分层设计
2.1 为什么必须做三层拆分
很多运营商的产品库失败，不是因为没有系统，而是把所有信息塞进了一张“产品表”。产品名称、速率、资费、合约期、受理渠道全混在一起，改一个价格就要复制一整个产品，最后表里的SKU数量动辄十几万，实际上真正不同的产品不超过几百个。
正确的做法是参照TM Forum SID模型，把产品库拆成三层：
- Product Specification（产品规范）：描述产品本身的能力，比如“下行1000Mbps、上行30Mbps、光猫类型、技术上是否支持FTTR”。它不关心怎么卖，只回答“技术上有什么”。
- Product Offering（产品供给）：描述怎么卖，包括定价、合约期、适用渠道、捆绑关系。同一款“千兆宽带”可以有不同的Offering，例如“月付型”和“年付优惠型”。
- Product Inventory（产品实例）：用户实际订购后形成的记录，关联到用户账号、安装地址、实际开通参数。
分层的好处是：技术能力只定义一次，销售形态可以随意组合；改价格不需要动技术定义；新增业务类型时只需要扩展Specification，不需要推翻现有目录。
2.2 实体关系与表结构
以下是最小可落地的五张核心表。
| 表名 | 含义 | 关键字段 |
|---|---|---|
| product_specification | 产品规范 | spec_id, spec_code, spec_name, category_id, attributes_json, status |
| product_offering | 产品供给 | offering_id, offering_code, offering_name, spec_id, price_plan_id, channel_ids, valid_start, valid_end |
| price_plan | 资费计划 | plan_id, monthly_fee, upfront_fee, contract_months, early_termination_fee |
| offering_relation | 供给关系 | relation_id, parent_offering_id, child_offering_id, relation_type |
| product_rule | 业务规则 | rule_id, rule_type, rule_content_json, priority |
对应的建表语句：
CREATE TABLE product_specification ( spec_id BIGINT PRIMARY KEY, spec_code VARCHAR(64) UNIQUE NOT NULL, spec_name VARCHAR(128) NOT NULL, category_id INT NOT NULL COMMENT '产品分类：1-宽带，2-IPTV，3-智能家居', attributes_json JSON NOT NULL COMMENT '技术属性，如速率、终端类型', status TINYINT NOT NULL DEFAULT 1 COMMENT '1-有效，0-失效' ); CREATE TABLE product_offering ( offering_id BIGINT PRIMARY KEY, offering_code VARCHAR(64) UNIQUE NOT NULL, offering_name VARCHAR(128) NOT NULL, spec_id BIGINT NOT NULL COMMENT '关联产品规范', price_plan_id BIGINT NOT NULL COMMENT '关联资费计划', channel_ids VARCHAR(255) COMMENT '可售渠道ID，逗号分隔', valid_start DATETIME NOT NULL, valid_end DATETIME );这里的关键是attributes_json字段。不要像传统表结构那样为每个速率、每个终端类型建列，否则每加入一种新能力就要做DDL变更。使用JSON类型存储可变属性，查询时用表达式索引过滤，既灵活又能保证基础字段的强约束。
2.3 用JSON表达产品目录
一份完整的Offering定义可以这样描述：
{ "offeringCode": "HBB-GB-1000M-2Y", "offeringName": "家庭千兆宽带两年合约版", "specification": { "specCode": "HBB-SPEC-GIGA", "category": "broadband", "downstream": "1000Mbps", "upstream": "30Mbps", "accessType": "FTTH", "supportFTTR": true }, "pricePlan": { "monthlyFee": 128.00, "upfrontFee": 0.00, "contractMonths": 24, "earlyTerminationFee": 200.00 }, "channels": ["online", "offline", "agent"], "validPeriod": { "start": "2025-01-01", "end": "2025-12-31" }, "rules": [ {"type": "mutex", "value": "HBB-PKG-LOW"} ] }参数说明：downstream和upstream属于Specification的技术属性，不随销售策略变化；monthlyFee、contractMonths属于Offering的销售属性，调整时不新建Specification；rules中的互斥对象指向另一个Offering编码。这样做的好处是，每次营销活动只需要新增一个Offering，关联同一个Specification，系统里不会堆积重复的产品定义。
3. 标准化产品库的配置工程：命名规则、属性模板与资费参数
3.1 产品编码规则
没有统一编码规则的产品库，从第一天开始就在制造数据混乱。常见做法是采用“业务域—产品线—序列号”三段式编码，用正则强制约束。
^([A-Z]{2})-([A-Z]{4})-([0-9]{4})$字段含义：
- 第一段业务域：
HB家庭宽带，ITIPTV，SH智能家居。 - 第二段产品线：
GIGA千兆，FTTR全屋光网，MESH组网。 - 第三段序列号：从 0001 开始，不得复用。
比如HB-GIGA-0001、HB-FTTR-0003。编码本身不包含资费信息，因为资费属于Offering，不应体现在编码里。如果某个产品在运营中被合并或废弃，保留编码，在状态字段里标记为“已废弃”，避免新编码顶替造成历史数据歧义。
3.2 属性模板的定义与继承
每个产品线有各自的属性集，但公共属性必须统一。用YAML定义属性模板，模板之间通过继承减少重复。
BaseAttributes: productCode: { type: string, required: true } productName: { type: string, required: true } status: { type: enum, values: [draft, approved, published, retired] } BroadbandAttributes: extends: BaseAttributes properties: downstream: { type: int, unit: Mbps, min: 100, max: 2000 } upstream: { type: int, unit: Mbps, min: 10, max: 200 } accessType: { type: enum, values: [FTTH, FTTB, FTTR] } staticIP: { type: bool, default: false } IPTVAttributes: extends: BaseAttributes properties: channelPackage: { type: string, required: true } videoQuality: { type: enum, values: [SD, HD, 4K] } multiScreen: { type: bool, default: false }属性继承的目的，是让新业务线不用从零定义。比如新增“云电脑”产品，基础属性直接用BaseAttributes，再补充CPU、内存、存储等扩展属性。
3.3 资费参数与定价模型
资费计划是Offering的重要组成部分，参数设置直接影响计费系统和结算系统。见下表。
| 参数名 | 类型 | 示例值 | 说明 |
|---|---|---|---|
| monthly_fee | DECIMAL(10,2) | 128.00 | 月租费，可为0 |
| upfront_fee | DECIMAL(10,2) | 400.00 | 一次性费用，例如安装费 |
| contract_months | INT | 24 | 合约期，0表示无合约 |
| early_termination_fee | DECIMAL(10,2) | 200.00 | 违约金的默认值 |
| billing_cycle | ENUM | 1,2,3 | 1-自然月，2-账期月，3-灵活周期 |
| discount_type | ENUM | none, first_months, total | 无优惠、前N月优惠、总额打折 |
在设计资费参数时，要区分“定价”和“折扣”。定价是业务基准价，折扣是促销活动。把促销折扣放进价目表里，会导致标准价格被不断覆盖，最终失去基准。常见做法是把折扣单独放到营销活动表，Offering只维护原价。
3.4 生命周期状态机
产品库中的每一条Specification和Offering都有生命周期，状态流转必须受控：
- draft：创建后默认为草稿，仅自己可见。
- approved：产品经理、资费主管、法务（如有）审核通过，允许发布。
- published：已生效，渠道可见，可被用户订购。必须设置生效时间。
- retired：停售但仍有存量用户，不可新订购。
- deprecated：全部用户迁转完成，数据仅归档保留。
发布操作要记录操作人、时间、版本号。每次修改不应直接覆盖，而是生成新版本，让历史订单能关联到当时的Offering版本。
4. 在BSS/CRM中落地产品库：数据表、导入脚本与互斥校验
4.1 从产品库到营业系统的主数据同步
产品库通常作为独立主数据平台，需要将审核通过的数据同步到BSS、CRM、电商中台等多个下游系统。同步的最小数据集是Offering编码、名称、价格、有效时间以及关联的Specification编码。增量同步的SQL示例：
INSERT INTO bss_product_offering (offering_id, offering_code, offering_name, spec_code, price_plan_id, valid_start, valid_end) SELECT o.offering_id, o.offering_code, o.offering_name, s.spec_code, o.price_plan_id, o.valid_start, o.valid_end FROM product_offering o LEFT JOIN product_specification s ON o.spec_id = s.spec_id WHERE o.status = 'published' AND o.updated_at > :last_sync_time;这段SQL只同步最近更新的数据。注意LEFT JOIN的判断：如果s.spec_code为NULL，说明Offering关联了不存在的Specification，这类数据应该拦截而不是强行同步。下游系统接收数据后，先入暂存表，校验通过再更新正式表。
4.2 用Python批量导入产品
很多产品库初建期，存量产品靠人工录入不现实。下面是用Python读取CSV批量导入的骨架脚本，支持dry-run模式。
import csv import json import sqlite3 import sys def load_csv(path): with open(path, encoding='utf-8-sig') as f: return list(csv.DictReader(f)) def validate_row(row): # 简单必填校验，实际需要检查code格式 required = ['offering_code', 'offering_name', 'spec_code', 'monthly_fee'] for k in required: if not row.get(k): raise ValueError(f"缺少字段 {k}: {row}") if len(row['offering_code'].split('-')) != 3: raise ValueError(f"编码格式错误: {row['offering_code']}") def insert_offering(conn, row): sql = """ INSERT INTO product_offering (offering_code, offering_name, spec_id, price_plan_id) VALUES (?, ?, ?, ?) """ cur = conn.cursor() # 实际应从spec表中查询spec_id，此处仅示意 cur.execute(sql, (row['offering_code'], row['offering_name'], row['spec_code'], row['price_plan_id'])) def main(path, dry_run=True): rows = load_csv(path) conn = sqlite3.connect('catalog.db') for row in rows: validate_row(row) if not dry_run: insert_offering(conn, row) if dry_run: print(f"dry-run 模式，共 {len(rows)} 条，无实际写入") else: conn.commit() conn.close() if __name__ == '__main__': main(sys.argv[1], dry_run='--commit' not in sys.argv)脚本逻辑说明：先读CSV，逐行做格式和必填校验，最后批量写库。dry_run默认开启，避免误操作。实际生产环境建议使用数据库事务，遇到失败行时回滚并输出行号。
4.3 套餐互斥与必选规则校验
家庭业务中，互斥规则最容易出问题。例如“千兆宽带方案A”与“千兆宽带方案B”互斥，“全屋WiFi”则可能依赖特定的宽带等级。规则表设计如下：
CREATE TABLE product_rule ( rule_id BIGINT PRIMARY KEY, rule_type ENUM('MUTEX', 'REQUIRED'), left_offering_code VARCHAR(64) NOT NULL, right_offering_code VARCHAR(64) DEFAULT NULL, priority INT DEFAULT 0 );校验逻辑用代码实现更清晰：
def check_rules(selected_offerings): rules = load_all_rules() violations = [] for rule in rules: if rule.type == 'MUTEX': if rule.left in selected and rule.right in selected: violations.append(f"互斥冲突: {rule.left} 与 {rule.right}") elif rule.type == 'REQUIRED': if rule.left in selected and rule.right not in selected: violations.append(f"必须同时订购: {rule.right}") return violations这里的核心是保持规则数据化，不要将规则硬编码在业务代码里。上线前至少用全量组合跑一遍规则校验，防止出现“用户能选购但受理时报错”的问题。
4.4 常见落地陷阱
落地过程中最常踩的坑有三个。第一，产品库与订单中心使用不同的产品编码，同步时靠名称匹配，这是最危险的，必须强制使用全局唯一的ID。第二，Offering的生效时间没有索引，导致查询当前可售产品时全表扫描，营销大促时数据库被拖垮。建议在valid_start和valid_end上建联合索引。第三，修改Specification的技术属性时，没有同步通知下游。比如把上行速率从30M改为50M后，存量订单可能受影响，必须走变更通知流程，至少提前一个账期告知结算系统。
5. 产品库的扩展与治理：从宽带向FTTR、全屋智能演进
5.1 动态属性扩展机制
家庭业务不断推出FTTR全屋光网、云电脑、智能安防等新形态，如果每次都在表中加列，成本太高。推荐使用扩展表方案。product_attribute_value表中保存offering_id、attribute_key、attribute_value、value_type，用“窄表”承载动态属性。查询时需要把多行Key-Value拼装成对象，在SQL中可以用GROUP_CONCAT配合 JSON 函数。Python端访问时默认返回字典：
def fetch_attributes(offering_id): rows = query("SELECT attribute_key, attribute_value FROM product_attribute_value WHERE offering_id = ?", offering_id) return {row[0]: row[1] for row in rows}这种方式的优点是新增业务不需要改表结构；缺点是属性校验分散。做法是维护一份属性元数据表，定义每个Key的类型、是否必填、可选值范围，写入时先校验元数据。
5.2 产品库健康度评估
治理产品库需要量化指标。推荐三个最实用的指标：SKU重复率（相同Specification和PricePlan的Offering数量占比）、规范覆盖率（符合编码规则的产品占比）、实效废弃率（超过1年未发布或被引用的Offering占比）。定期用SQL统计：
SELECT COUNT(*) AS duplicate_count, COUNT(DISTINCT CONCAT(spec_id, '-', price_plan_id)) AS unique_count FROM product_offering WHERE status != 'deprecated';如果duplicate_count / unique_count超过1.2，说明Offering定义冗余。建议每月生成一次治理报表，将高重复率的产品线标记为待整合，给产品经理提供合并依据。
5.3 用方案文档对齐部门认知
对于“运营商家庭标准化产品库方案.pptx”这类型的交付物，关键在于用一页图说清分层模型，用一页表列出命名规则和必填参数，用一页流程图展示发布与下线流程，再配一份字段级的数据字典附录。PPT的价值不是炫技，而是让市场部、产品部、BSS研发和运维在同一个认知框架下讨论问题。当你把上述表和脚本放进演讲者备注，再把状态机和互斥规则画成分镜，方案才能真正进入实施阶段。
产品库上线后，建议每隔两个季度重新核对一遍属性元数据，删除无被引用的废弃属性，合并名称含义相似的速率档位。标准化不是一次性项目，而是持续的数据治理过程。最终的目标很朴素：任何家庭成员业务，无论从哪个渠道进来，系统对它的定义只有一个。
本文还有配套的精品资源，点击获取
