企业官网建设流程全解析

简介：中国南方航空数字化与双中台方案演示文稿，系统呈现南航在数字化转型中的顶层设计与落地经验，面向企业数字化负责人、中台架构师及行业研究者。方案重点阐述业务中台与数据中台的建设思路，通过标准化、模块化能力复用，解决重复投入与效率瓶颈。资源包含1个演示文稿文件（pptx格式），大小约1.1MB，内容涵盖南航数字化管办分离体系、科技创新平台（含五小创新、人工智能重点实验室）、流程与人才机制，以及航班中心、大兴机场转场通告快速分析、业务人员自助BI等具体案例。已有98人学习下载。适合需要参考大型央企数字化转型路径，或希望了解双中台在民航业落地方法的读者，可快速掌握南航从组织保障到技术平台的全景实践，包括管办分离的信息化治理、业务中台航班中心微服务划分、数据中台基于QuickBI的自助分析与大兴机场转场通告快速出数案例。

1. 这份数字化与双中台方案，到底在给南航解决什么

航空公司可能是传统企业里IT系统最复杂的一类：离港、订座、常旅客、货运、销售、结算、运行控制，每一套都是十几年甚至二十几年攒下来的老系统，各自有独立的数据库和接口协议。所谓“数字化+双中台”，本质上是把这条七横八竖的系统烟囱，改造成“前台轻、中台厚、后台稳”的新架构，让新业务上线不用再等老系统排期。这份方案面向的人很具体——航司IT架构师、数字化推进办成员、以及给航司做乙方售前的解决方案顾问。它的价值不在PPT画得多漂亮，而在能不能把“业务中台管共享流程、数据中台管共享数据”这两层逻辑拆成可执行的建设节奏，落地时少走弯路。

2. 为什么航司需要双中台：从业务痛点倒推架构选型

2.1 航司IT的典型病根：一个旅客信息散落在六套系统里

我接触过的航司客户，几乎没有哪家能在一分钟内说清楚“一个高价值旅客在全渠道到底产生了哪些行为”。原因不复杂：官网注册走电商系统的库，值机走离港系统的库，里程累积走常旅客系统，投诉工单在客服系统，APP埋点数据又单独进数仓。每个系统都认一套会员标识，手机号、证件号、常旅客卡号、护照号各自为政。这直接导致三个后果：旅客体验割裂、营销活动无法精准圈人、数据团队花70%的时间在对数和清洗上。

双中台的第一步，就是要从架构上终结这种“各管一段”的现状。业务中台把跨系统都要用的能力抽出来——会员统一认证、订单中心、产品组装、促销引擎——变成一组共享服务；数据中台则把这些服务产生的数据连同老系统的历史数据，重新加工成统一标签和指标。一个管“写”，一个管“读”，分工清楚。注意，这里说的绝不是推翻老系统重来，航司的离港系统是AOC（运行控制中心）级的核心，没人敢动。常见做法是老系统继续保留，但在它前面加一层中台做能力封装和数据汇聚。

2.2 业务中台与数据中台的边界，用“写路径”和“读路径”一刀切

很多方案把双中台画成两个并列的大平台，落地时却经常边界打架：业务中台的订单数据要不要进数据中台？数据中台算出来的标签要不要回写给业务中台？我一般建议用一条最朴素的准则切分——业务中台承载所有在线交易链路的共享能力，它保证的是“这个订单在创建时状态正确、库存够扣、会员等级能识别”；数据中台承载所有离线分析链路的共享能力，它保证的是“这个旅客的画像标签可以被营销系统批量查询”。业务中台的数据必须准实时地流向数据中台，但数据中台的分析结果只在需要反哺在线场景时才写回业务中台，且要经过API而不是直接连库。

这里有一张我常用的能力边界对照表，基本能覆盖航司双中台方案的第一轮讨论：

按这个表去读方案里的架构图，基本能一眼看出哪些模块放错了位置。比如“航班延误预测”被画进业务中台，就属于典型的边界混淆——延误预测是分析产物，它应该运行在数据中台，预测结果再通过接口喂给前端APP推送服务，而不是在业务中台里跑一套预测模型。

2.3 为什么是“双”中台而不是一个中台，也不是上云就完事

单中台的思路是把所有共享能力放一个篮子里，在航司这种组织里很难走通，因为业务中台和数据中台背后的团队KPI完全不同：前者考核的是接口稳定性、可用率、需求响应速度，后者考核的是数据质量、标签覆盖度、模型效果。混在一个项目组里，必然出现一个团队忙死、另一个团队没事干的局面。分而治之，表面上是架构选择，实际上是组织匹配。

至于“上云就能数字化”的说法，在航司场景下尤其不成立。南航这类航司的生产系统受制于安全合规和运行保障要求，核心交易链路不可能全量上公有云。双中台的价值恰恰在于：它可以骑在混合架构上，无论底层是物理机、私有云还是公有云，中台对外输出的都是标准API和数据服务，让上层应用感觉不到底层的割裂。这也是方案里把标准和规范放到很高位置的原因，没有统一的服务规范和数据规范，双中台就只是给老系统换了个调用方式。

3. 把PPT拆成可落地路径：中台建设顺序与模块拆分

3.1 先建会员域，还是先建订单域？顺序决定了项目生死

一份双中台方案如果不写清楚建设顺序，落地时大概率会变成“哪里缺人就先建哪里”，最后做成一锅夹生饭。我见过的成功路径，第一枪基本都是打向会员域。理由很简单：航司最值钱的资产是高频常旅客，而常旅客数据散落最严重、业务方最痛、最容易在短期内做出可感知的成效。会员域统一之后，紧接着建订单域——因为机票订单是交易主链路，所有产品（行李、选座、餐食、保险、酒店）都要挂到订单上。这两个域稳定之后，再扩展营销域和产品域。

这个顺序背后的逻辑是“先打地基再盖房”：会员域提供Who am I，订单域提供What I bought，有了这两个，后面的推荐、促销、数据分析才有数据基础。方案里如果写的是“全面铺开、六域齐建”，建议直接打回重做，因为在航司这种复杂环境里，多线并行意味着每个业务方都要配合改造，配合意愿和配合质量都会急剧下降。

3.2 从PPT架构图到系统边界清单，这一步不能省

很多团队拿到方案PPT就直接进入编码阶段，这是最危险的动作。PPT里的“会员中心”只是一个方块，但落库时你得知道：会员基础信息表在哪个库？等级变更记录放哪里？权益发放要不要发消息？老常旅客系统的数据怎么同步？我建议第一步先把PPT里的每个框翻译成一张“系统边界清单”，包含服务名、所属域、读写类型、依赖的老系统、数据流向、接口协议，格式类似下面这样：

这张表比任何架构图都值钱。架构图只告诉你“我要建一个会员中心”，这张表告诉你“会员中心要接哪五个系统、每天同步多少数据、消费方是谁、挂了我该通知谁”。我一般会用这张表跟每个业务方过一遍，确认他们对“数据从哪来、到哪去”没有异议，再进入开发。这一步花了时间，后面联调至少省三倍。

3.3 中台服务的最小可交付单元：一个会员统一查询服务的定义

落地时不要一上来就建一堆服务，先把一个最核心的服务做出样板。以南航场景为例，第一个服务通常是“会员统一查询服务”——把常旅客号、身份证、手机号、会员ID统一映射到一个旅客视图上。这个服务的接口定义，我建议用OpenAPI规范写清楚，因为它的调用方至少有APP、客服、营销、地面服务四个系统，接口不清晰后面全是扯皮。一个最小化的接口定义大致长这样：

openapi: 3.0.0 info: title: Unified Member Query Service version: 1.0.0 paths: /v1/members/{member_id}: get: summary: 查询统一会员信息 parameters: - name: member_id in: path required: true schema: type: string - name: id_type in: query required: false schema: type: string enum: [FFP_NO, ID_CARD, MOBILE, PASSPORT] responses: '200': description: 返回统一会员视图 content: application/json: schema: type: object properties: one_id: type: string description: 全局唯一旅客ID ffp_no: type: string description: 常旅客卡号 tier: type: string enum: [SKY_TEAM_ELITE, GOLD, SILVER, BLUE] mileage_balance: type: integer description: 里程余额 linked_members: type: array items: type: string description: 已绑定的其他会员账号

这段定义背后有几个关键设计逻辑：id_type参数让调用方可以用任何一种既有标识来查会员，不用先自己维护一套映射关系；返回体里的one_id是数据中台加工出来的全局ID，业务中台服务直接消费它，而不是自己再造一套ID；linked_members字段是给客服场景用的，处理“家人账号绑定”这类需求时不用再跨系统查。这两个设计，就是业务中台和数据中台合作的最典型样例——业务中台提供在线查询能力，数据中台提供ID映射的加工结果。

4. 数据中台在航司的落地细节：埋点、标签体系与实时链路

4.1 全渠道埋点统一，否则标签体系就是空中楼阁

数据中台最容易被低估的环节是埋点。很多航司的APP、小程序、自助值机设备、机上WiFi门户各有各的埋点规范，同一个“点击值机”事件，在APP里叫checkin_click，在小程序里叫value_machine_click，数据中台接入之后光做名称映射就要耗掉两周。我见过最快的解决方案，是上线一套强制的事件规范，所有端必须按统一schema上报，违规埋点一律不接入数仓。下面是一份最小可用的埋点事件规范示例，字段不多，但足够支撑绝大部分分析场景：

{ "schema_version": "1.2", "event_name": "checkin_click", "event_id": "uuid", "timestamp": "2024-06-01T10:23:45+08:00", "channel": { "channel_id": "APP_IOS", "app_version": "5.3.1" }, "user": { "one_id": "M_20240601001", "is_login": true, "ffp_tier": "GOLD" }, "context": { "page": "checkin", "route": "home_checkin_btn" }, "properties": { "flight_no": "CZ3101", "dep_airport": "CAN", "arr_airport": "PEK", "checkin_method": "auto" } }

这份规范的要点：event_name是人读的，event_id是机器查的，一条事件缺了后者就没办法做去重和排障；user.one_id是数据中台回传给端上的，端上只管透传，这样分析侧才能统一按one_id拉全旅程行为；properties里放的是动态业务字段，允许各端扩展但不能改名。执行层面，我通常建议在数据中台前面加一个校验层，schema不合法的事件直接进隔离队列，宁可丢数据也不要脏数据。等埋点规范稳定运行一个月，再开始建标签体系，否则标签加工出来的东西全是垃圾。

4.2 旅客标签体系怎么建：从RFM分层到OneID打通

标签体系是数据中台最容易“自嗨”的部分。业务方张口就要“高价值旅客”“流失倾向”“亲子人群”，但你要先回答一个基础问题：这些标签的加工逻辑是什么？我一般从RFM入手，因为它是航司场景里最通用、业务方最容易认可的一套逻辑。用SQL写一个简化版的高价值旅客分层，跑在数仓的离线调度里，大致长这样：

WITH rfm AS ( SELECT one_id, DATE_DIFF(CURRENT_DATE, MAX(flight_date), DAY) AS recency, COUNT(DISTINCT order_id) AS frequency, SUM(passenger_revenue) AS monetary FROM dwd_flight_order_detail WHERE flight_date >= DATE_SUB(CURRENT_DATE, 365) GROUP BY one_id ), rfm_score AS ( SELECT one_id, CASE WHEN recency <= 30 THEN 4 WHEN recency <= 90 THEN 3 WHEN recency <= 180 THEN 2 ELSE 1 END AS r_score, CASE WHEN frequency >= 6 THEN 4 WHEN frequency >= 3 THEN 3 WHEN frequency >= 1 THEN 2 ELSE 1 END AS f_score, CASE WHEN monetary >= 50000 THEN 4 WHEN monetary >= 20000 THEN 3 WHEN monetary >= 5000 THEN 2 ELSE 1 END AS m_score FROM rfm ) SELECT one_id, r_score, f_score, m_score, (r_score * 100 + f_score * 10 + m_score) AS composite_score, CASE WHEN r_score >= 3 AND f_score >= 3 AND m_score >= 3 THEN '高价值活跃' WHEN r_score <= 2 AND f_score >= 3 THEN '沉睡高价值' ELSE '普通' END AS tier_label FROM rfm_score

这段SQL看起来简单，但踩坑点都在细节上：dwd_flight_order_detail这张表必须已经是OneID打通后的明细表，如果还停留在“按会员卡号关联”的阶段，跑出来的数据会漏掉用手机号下单但没绑卡的用户；DATE_SUB往前取365天是行业常用窗口，但航司旺季和淡季差异大，我建议至少要和去年同期做对比，否则夏季做的模型到了冬季会严重偏移。这套标签做好后，最大的受益方是营销系统——圈选人群从“手动导出Excel”变成“中台API实时查询”。

4.3 实时链路：航班动态和延误信息怎么支撑前台体验

航司数据中台里，实时计算链路的优先级比离线报表高得多，因为航班动态直接影响旅客的现场体验。一条典型的实时链路：航班起降数据从AOC系统出来，经过消息队列进入数据中台的实时计算引擎，关联天气、管制、前序航班状态，生成一个“延误预估”结果，再推送到达APP的弹窗。端到端延迟要求一般在30秒以内，超过这个阈值，旅客可能已经走到登机口才发现登机口改了。

实时链路里最容易被低估的是数据质量监控。流式计算框架本身的稳定性经过几年发展已经比较可靠，真正的黑匣子是输入数据的准确性——AOC发出来的某个航班状态字段突然变了枚举值，实时任务不会报错，但会把“正常”算成“延误”。我一般会在实时链路里加一个“跨源校验”的步骤：航班状态同时从AOC和机场地面系统取数，两者不一致时默认取更保守的值并告警。这条规则看起来简单，但能避免大量“系统显示延误、旅客到了机场发现没延误”的投诉。

4.4 文创IP数字化：被忽略的航司第二增长曲线

现在航司做文创已经是普遍趋势，飞机模型、联名周边、主题文创在电商渠道的销量逐年上升。这个场景和双中台有什么关系？关系非常大——南航这类航司的文创电商如果挂在老电商系统上，会员积分兑换文创礼品要走常旅客系统，库存管理要走ERP，物流查询走第三方快递接口，每一段都是孤岛。双中台在文创IP数字化里的价值，是把“积分兑换+现金购买+会员权益”三种交易形态统一到订单域，把文创商品的浏览、加购、兑换行为统一进数据中台的行为标签体系。后面做IP联名推广时，可以直接用数据中台的画像圈出“收藏癖人群”“亲子人群”“飞友人群”分别推送不同文创品类，而不是群发短信。

5. 双中台建设的5个常见坑：现象、原因与解决办法

5.1 中台变成“大烂账”：所有接口都往中台塞

现象：中台上线半年后，服务数量涨了三倍，但每个服务的调用量都很低，团队陷入“为抽象而抽象”的泥潭。原因是没有定义中台能力的准入标准，任何系统说一句“我要接中台”就被纳入建设范围，最后中台变成了新的ESB。解决：引入“双业务方原则”——一个能力必须至少被两个独立的业务方使用，才有资格进入中台；只有单一业务方需要的逻辑，留在前台自己实现。这个标准在每次架构评审会上都要重申，否则半年后就没人记得了。忠言逆耳，但这条最管用。

5.2 数据中台变成了报表中心

现象：数据中台上线后，业务方天天提“我要看XX报表”，数据团队疲于奔命交付报表，但业务决策并没有更智能。原因：业务方的思维惯性是“你给我东西看”，而不是“我把我的系统接上你的服务”。解决：数据中台考核指标从“交付报表数量”改为“数据服务被调用次数”，在需求评审时问一句“这个报表是要给人看，还是要被系统调用？”——如果说不出系统消费方，就放到BI工具里让业务方自己拖拽，不进中台建设范围。这一条能把中台的边界护住，不然数据中台就是个升级版数仓。

5.3 OneID映射比想象中难，手机号不是万能键

现象：会员打通项目做了一半发现，同一个旅客在常旅客系统里是卡号A，在电商里是手机号B，两者没有关联关系，合并后产生大量重复ID。原因：手机号可以换、可以一人多号、可以家人共用，不能作为唯一的确定性标识。解决：建OneID映射表，按“证件号 > 常旅客卡号 > 手机号”的优先级做置信度加权匹配，低置信度的对不上的先进人工审核池。我见过最稳的做法是：上线初期只对数据中台内部开放one_id，等映射准确率稳定在95%以上，再回写给业务中台对外开放。不要一上来就追求100%准确率，那是不可能的，先跑起来、跑起来才能发现问题。

5.4 老系统不改造，中台和老系统两边数据对不上

现象：中台已经上线了，但老系统还在被其他渠道继续写入，两边数据每天对账都有差异。原因：并行期没有明确“数据权威源”，老系统和中台都在改同一份数据，冲突是必然的。解决：建立数据源分级制度，每个数据实体只允许一个系统做写操作。在过渡期，让老系统继续作为权威源、中台异步同步，还是让中台作为权威源、老系统反向同步？我的判断标准是：核心交易链路（如出票）先让老系统保持权威，边缘场景（如会员资料修改）优先切换到中台，边切换边对账，分批次收编。这里对账脚本要提前写好，每天自动跑，差异数据进队列让业务方确认，不能只靠开发手动查库。

5.5 业务中台和数据中台边界打架，数据到底归谁管

现象：做标签回写时，业务中台说“这是数据中台的表，我不管”，数据中台说“这是在线交易的数据，应该你负责”，两边扯皮。原因：切入时就只画了架构图，没定义“读路径”和“写路径”的交接协议。解决：写清楚一条细则——业务中台负责所有在线事务的写操作和数据一致性，数据中台负责所有分析型数据的加工和存储；数据中台把加工结果回写业务中台时，必须通过API且由业务中台编码落库，数据中台不允许直连业务中台的库。这一条写进开发规范里，比反复开协调会管用。做双中台最怕的不是技术难度，而是权责不清造成的组织内耗，这是所有坑里最贵的一个。

6. 中台上线后怎么验证价值：一个可复用的度量方法

中台建设最怕的一件事，就是上线时轰轰烈烈、验收时却拿不出业务价值。我常用的验证方法，不是看服务数量、不是看数据总量，而是盯住“一个典型业务需求的交付周期”。具体做法：选一个改造前要跨五个系统手工协作的场景——例如“新增一种会员权益类型，全渠道同步生效”——在旧架构下，这个需求的交付周期通常是四周加两次跨部门评审。中台上线三个月后再做同一个需求，记录从业务提需求到全渠道生效的时间。如果这个周期没有缩短到原来的三分之一以下，那中台一定哪里建歪了，别听任何汇报，数据不会骗人。

除了需求交付周期，我还会盯两个过程指标：中台服务的复用率（被两个及以上业务方调用的服务占比，目标是60%以上）和数据API的周调用次数趋势。这两个指标不太会被美化，因为它们直接体现在监控系统里。做双中台这几年，我最大的教训是：不要追求“大而全”地一次性把中台做完美，也不要被PPT上的宏大叙事带偏节奏。先锁死一个业务域，把它打成样板——让业务方切实感受到“原来三天的活现在三小时能完成”，后面所有抵抗都会变小。这个方向值不值得投入，不看选型报告，就看跑完样板业务域之后业务方还愿不愿意继续配合你往下建。希望帮到你。

本文还有配套的精品资源，点击获取