简介《中国南方航空数字化和双中台方案》演示文稿源自南航数字化转型一线实践聚焦智慧城市、大数据、互联网与人工智能应用场景面向企业数字化负责人、中台架构师及相关技术人员解决传统信息化建设中重复造轮子、响应慢、数据壁垒高等痛点。包内仅1个pptx文件大小约1.1MB轻量便携便于直接用于内部研讨或方案借鉴。目前已有98人学习。内容系统梳理了南航数字化管办分离体系、创新机制含科学技术委员会、人工智能重点实验室、五小创新等、流程管理、人才培养并拆解双中台落地细节业务中台以航班中心整合航班全流程数据为营销、机务等系统提供标准化模块服务数据中台通过《大兴机场转场通告》等案例展示报表快速响应业务人员借助自助分析工具可在2小时完成仪表板、1天完成数据门户。整体兼顾顶层设计与执行方法对智慧城市、大数据、人工智能相关从业者具有实用参考价值。1. 南航双中台方案为什么中台在航司比在互联网公司更好讲做数字化转型的人多少都有这种体会中台这个词被互联网公司讲烂了落到传统行业却常常水土不服。中国南方航空的数字化和双中台方案是少有的把中台讲得比互联网公司还实在的一份材料——它不堆技术名词而是把中台定位成“解决慢和贵问题的企业级能力复用平台”用航班中心整合全生命周期数据用数据中台把报表交付周期从一个月压到一天。这份PPT值得反复读的不是几张架构图而是它把组织、流程、人才和两个中台绑在一起讲透了。适合正在做数字化转型规划、中台建设立项或者被报表需求压得喘不过气的数据团队仔细看。2. 业务中台与数据中台航班中心怎么把全生命周期数据变成可复用能力2.1 中台的定位先解决“慢”和“贵”再谈技术平台南航对中台的定义很克制把可复用的功能或能力进行标准化、模块化管理是企业级能力复用平台通过减少“重复造轮子”解决“慢”和“贵”的问题。这句话信息量很大。传统航司信息化建设往往是项目制今天营销部门建一个航班查询接口明天机务部门又建一个后天地服部门再建一个接口越堆越多维护成本越来越高这就是典型的“慢”和“贵”。中台要做的事情是把这些重复能力收编、标准化变成企业级服务。南航特别强调中台更是理念、是架构是企业内部全体组织利用平台化手段发现、沉淀与复用企业级能力的过程。这句话的意思是不要指望上一个中台平台就万事大吉组织里的人愿不愿意把能力沉淀到中台、愿不愿意复用别人的能力才是中台能不能转起来的核心。在航司做中台比互联网公司更合适的原因在于航司的业务域高度集中核心就是航班围绕航班衍生出营销、机务、地服、空勤、货运这些系统。航班全生命周期数据的边界是清晰的天然适合做能力复用。这比互联网公司那种业务边界模糊、组织调整频繁的环境要友好得多。2.2 业务中台航班中心的四种服务形态南航业务中台以航班中心为核心整合航班全生命流程数据为全公司各业务系统提供服务。服务形态有四种PPT里把它归纳为服务形态说明典型场景标准化所有系统按同一套接口规范调用不因业务部门差异而变化航班时刻查询、航班状态同步定制化在标准服务基础上按需扩展字段或逻辑满足特定系统要求机务维修计划对航班动态的定制视图共享化一个服务被多个业务系统同时复用避免重复建设航班动态推送、旅客行程关联模块化把复杂业务拆成可组装的服务单元按需组合值机、行李、配载、登机服务组合航班中心把这些服务注册到企业级运行协作平台上营销系统、机务系统、地服系统、空勤系统、货运系统都通过平台调用不再各自建一套。这样系统之间的耦合度降下来了新业务上线时只需要组装已有服务不需要从零开始。2.3 业务中台落地四步走和两个关键参数航班中心的建设思路可以拆成四步做业务中台规划时可以照这个顺序走梳理航班全生命周期阶段从航班计划、座位销售、值机登机到飞行运行、维修保障画出完整流程地图。圈定各阶段里的共性能力比如航班状态变更、旅客信息同步、舱位库存查询这些是高频复用的部分。定义服务契约明确接口字段、调用方式、权限边界这一步决定服务能不能被其他系统顺畅接走。把服务部署到企业级运行协作平台上带着调用方的反馈持续迭代服务版本。两个关键参数值得盯一是服务复用率也就是多个业务系统在用的服务占全部已发布服务的比例低于三成说明拆出来的大量服务没有被复用属于自嗨二是服务响应时间航班运行是实时场景航班状态推送类服务要求在秒级以内超过这个标准就要考虑是不是服务拆得太细导致链路变长。航班中心还有一个容易被忽略的设计数据反馈。各业务系统调用服务后产生的业务数据要回写到航班中心形成完整的数据闭环。没有这个闭环业务中台只是接口网关不是能力平台。2.4 数据中台公共层先行报表交付从“按月”到“按天”数据中台的典型成果是《大兴机场转场通告》这个需求。时间线拉出来非常直观时间动作9月28日AOC运行控制中心提出报表分析需求9月28日数据团队评估数据中台公共层已具备数据条件9月29日BI报表开发、数据验证、投入使用9月30日报表正式交付给业务使用三天交付一张报表在过去是不可想象的。传统做法是业务提需求数据团队排期ETL开发两周报表开发一周测试验证一周一个月就过去了。南航能三天交付核心原因是公共层已经提前准备好了——这就是数据中台和传统数仓最大的区别。数据中台的分层逻辑大致是这样贴源层原样接入各业务系统的原始数据保留全部细节用于追溯。公共层把跨系统共用的数据统一口径、统一清洗形成企业级的数据资产这是去重的核心。应用层面向具体报表和应用场景生成数据比如大兴机场转场航班运行分析直接基于公共层聚合。公共层建得好不好决定了报表需求能不能快速响应。南航数据中台评估公共层已具备数据条件意味着航班、旅客、运行这些核心数据已经标准化不需要每次从头做数据清洗。2.5 数据中台自助分析把报表能力交还给业务数据中台建设到后期南航开始鼓励业务人员自助分析。借助数据中台的数据资源配合QuickBI工具经过培训的业务人员可以在2小时内完成仪表板搭建1天内完成数据门户开发。这个效率提升的背后是公共层数据已经足够干净、口径统一业务人员不需要懂SQL也能拖拽出分析页面。这里有一个选型逻辑QuickBI这类BI工具要发挥作用前置条件是公共层数据的维度、指标已经定义好。很多团队买了BI工具却用不起来就是因为底层数据一团乱麻业务人员拖出来的数对不上自然不信。南航的做法是先花力气做公共层再推自助分析顺序不能反。自助分析还有一个隐性好处把数据团队从低价值的取数工作中解放出来。过去业务要一张报表数据团队要排期开发现在业务自己就能搭仪表板数据团队只需要在公共层和指标层做维护。这样数据团队才有精力去做更深入的数据挖掘和业务分析而不是整天写SQL。3. 数字化转型体系管办分离、创新机制、流程管理、人才梯队四张牌3.1 管办分离科信部管“建什么”信息中心管“怎么建”南航数字化管理体系的骨架是“管办分离”原则三个角色权责切得很清楚角色职责对应问题科技信息与流程管理部科信部投资决策、项目评价建什么信息中心建设实施、信息化基础设施、网络安全怎么建业务部门需求提出为什么要建这个分工看着简单实际执行中很容易走样。最常见的问题是科信部把项目批了之后就不管了等系统上线了才发现业务根本不用或者是信息中心既当运动员又当裁判员自己给自己批项目自己验收。南航把项目评价放在科信部建设实施放在信息中心需求提出放在业务部门等于给每个环节都上了约束——项目做得好不好不是建设方自己说了算。这套机制对双中台建设尤其重要。中台项目投入大、周期长、收益不直观如果没有管办分离很可能出现信息中心闷头建了一年业务部门根本不认的情况。科信部管投资决策意味着中台项目立项时就必须回答业务价值的问题这倒逼建设过程始终以业务需求为导向。3.2 创新体系从五小创新到人工智能重点实验室南航的创新体系分三层顶层是科学技术委员会中间是民航维修工程技术研究中心、民航航空公司人工智能重点实验室这类专业平台基层是明珠创新工作室和“五小创新”小发明、小革新、小改造、小设计、小建议。这套体系的厉害之处在于覆盖了从战略研究方向到一线员工微创新的全链条。民航维修工程技术研究中心和人工智能重点实验室是由南航与中国民航大学共建的已被民航局正式认定并挂牌。这种产学研结合的模式解决的是企业自建研发团队的短板——高校提供理论研究和人才储备企业提供业务场景和数据成果直接落地到维修工程和航空运行场景中。对于做中台的人来说创新体系还有一个实际价值它是双中台的需求输入源和创新产品的孵化器。五小创新看似不起眼但一线员工提出的改善建议往往是最贴近业务的。比如值机员发现某个操作路径太繁琐机务工程师觉得维修记录录入效率低这些反馈经过明珠创新工作室筛选后可能会变成业务中台上的一个小服务也可能成为数据中台的一个分析主题。创新体系和中台形成正循环创新产生需求中台承载需求能力沉淀后反哺更多创新。3.3 流程管理体系用技术固化流程而不是靠制度文件南航成立了企业架构与流程管理委员会来统筹这件事核心动作是梳理公司流程架构、优化业务级流程然后通过技术手段固化业务流程。流程如果只停留在制度文件层面执行起来就会走样只有固化到信息系统里才真正算数——这也是企业架构和流程管理对双中台最实际的价值。流程管理落到执行层面遵循的是“流程绩效运用”这个抓手梳理出来的流程要能衡量绩效比如值机流程的平均耗时、航班延误时的应急响应流程流程绩效数据从哪里来从数据中台来。流程绩效运用包括流程管理与激励制度体系挂钩流程优化做得好不好直接影响到部门绩效评估。这里面有一个很多企业容易搞反的地方先画流程再上系统而不是先看系统能力再定流程。南航的做法是流程梳理和优化业务级流程在前通过技术固化业务流程序在后先想清楚业务应该怎么跑再让IT系统去支撑。中台项目如果跳过流程梳理直接上系统等于把原来的低效流程自动化结果只会更糟。3.4 人才培养从人才画像到选育用留的全生命周期管理南航的人才体系把数字化人才作为独立的人才类别来管理打通了“选育用留”全链路环节关键动作核心产出人才定位明确复合型数字化人才标准区分技术型、业务型、复合型人才画像筛选入库从现有员工中筛选具备数字化潜质的人员进入人才库梯队库池培养管理按全生命周期制定培养计划轮岗、项目锻炼、专业培训培养方案考核出库定期人才盘点考核合格者出库进入关键岗位不合格者继续培养人才盘点报告价值创造通过岗位任用、项目负责、创新激励实现价值兑现人才激励体系数字化人才画像这个工具值得细说。很多人力资源部门做人才画像容易做成“学历证书”的简单标签南航强调的价值在于把画像落到具体维度上技术宽度懂不懂数据、懂不懂系统架构、业务理解懂不懂航班运行、维修、营销这些业务场景、数据能力能不能用数据工具做分析、项目管理能力能不能推动跨部门协作。这些维度的数据从哪里来数字化人才库本身就是在数据中台上做的人才盘点技术手段和业务场景在这里完美闭环。复合型数字化人才梯队库池这个设计本质上是在企业中建一个内部人才市场。各业务部门有数字化项目需求时可以直接从中台人才库找人项目结束后人才回到库池。这样既锻炼了人才又保证了数字化项目有懂业务又懂技术的人来主导避免了业务部门和技术部门互相听不懂话的尴尬。4. 双中台落地常见问题5条踩坑记录与排查路径4.1 现象报表需求排了一个多月业务等部门等得失去耐心原因数据团队接到需求后才开始从贴源层找数据、清洗数据、开发报表公共层根本没有覆盖这个业务域。数据中台如果只建了贴源层没有沉淀好公共层每一次报表需求都是一次全新项目一个月的排期是必然结果。解决把公共层覆盖率当成数据中台的第一KPI来管在数据中台建设期先盘点高频报表依赖的公共数据实体按航班、旅客、销售、运行这几个域优先补齐公共层。业务侧提交报表需求时按“评估公共层是否已具备条件”作为第一步来走公共层已有的直接排期到小时级交付公共层缺失的走数据资产补充流程建设周期另算。4.2 现象业务中台上线后接口调用越来越乱部分系统绕过中台直连数据源原因业务系统觉得中台服务满足不了特定需求或者嫌走中台多一跳响应慢又改回直连数据库的老路。中台服务如果不够标准、不够好用业务系统宁可走回头路这其实不是业务系统的问题是中台治理机制没建立起来。解决把企业级运行协作平台变成唯一的数据通道从网络层面和账号权限层面收紧对数据源直连的管控。用服务调用审计日志来看绕过行为这是中台运维要盯的第一个指标服务发布时必须带调用方认证数据源侧不对业务系统开放直连账号。中台团队要定期review服务调用量调用量很低或者被绕过的服务要么是服务设计有问题要么是业务侧没有迁移过来都要专项处理。4.3 现象业务人员用QuickBI拖出来的仪表板数据和报表团队开发的对不上原因指标口径口径不统一是常见问题。比如“航班准点率”这个指标运行部门按航班关门时间计算营销部门按起飞时间计算两边数对不上很正常。数据中台把数据统一收集了但指标定义没有统一等于中台把数据汇聚到了一起却没有把口径拉平业务自助分析自然翻车。解决建立企业级指标字典每个指标指定一个口径owner所有报表和自助分析都从指标字典引用口径定义。第一时间把公共层存量的指标全部梳理出来逐一定义计算逻辑和维度的约定再把这个指标字典嵌入到BI工具里。业务人员新建仪表板时看到他选用的指标的计算口径说明让整个过程的透明度更高、更便于理解报表团队和自助分析用同一套口径数对不上这个问题基本绝迹。4.4 现象数据中台只有IT在推业务部门到了验收阶段才开始提意见原因数据中台建设期把业务部门当成最终用户而不是共建方业务部门没有深度参与建什么、怎么建只在最终验收时被动看效果。这也提醒我们数据中台如果只被IT部门抱着业务价值就说不清验收时很难获得业务认可。解决让业务部门直接参与公共层的指标定义和优先级排序。在数据中台项目初期按业务域划分专题小组由业务骨干担任数据产品经理角色对公共层的数据质量、指标口径、分析场景负责。培养业务人员自助分析能力让会用的业务人员在各自部门产生示范效应是最有效的中台推广方式。4.5 现象中台项目上线即巅峰半年后服务没人维护数据没人更新原因中台没有运营责任主体。项目团队成员在验收后回到了原来部门中台服务发现问题找不到人修数据质量问题没人认领中台快速腐化。中台是一个需要长期运营的能力平台不是一个交付完就结束的项目。解决在立项时就把中台运营团队编制明确下来日常运营至少覆盖服务治理、数据质量、指标维护三个角色。服务上线时必须登记ownerowner对服务生命周期负责数据质量建立月度巡检机制数据更新延迟超过阈值要自动告警。把中台的复用率、报表交付周期、数据质量这些指标纳入运营团队绩效考核中台才不会验收即结束。5. 验证中台有没有用用一个报表需求走完整个闭环5.1 六步闭环验证法中台项目最怕说不清价值。我把PPT里的逻辑结合实操经验整理成一个六步闭环验证法每接一个中台项目就照这个走一遍挑需求选一个业务价值明确、跨系统取数、过去响应周期超过两周的报表需求。查底座直接看数据中台公共层有没有覆盖报表涉及的核心数据实体先看表和指标的覆盖情况再看更新时效。定口径和业务确认指标计算逻辑看是否已存在于指标字典没有就先补建。快交付交付过程用BI工具完成先看是否能快速出雏形优先复用已有公共层模型。交叉验证拿报表结果和业务系统的原始台账做比对验证数据链路正确性。复盘沉淀评估这个需求复用了哪些中台服务沉淀了什么新的数据资产可复用到同类需求。第5步的交叉验证是关键用的SQL逻辑很直接-- 抽查校验报表口径把中台公共层结果与业务系统台账汇总做对比 SELECT dim.flight_date, dim.flight_no, SUM(fact.passenger_cnt) AS pax_cnt, SUM(fact.luggage_cnt) AS luggage_cnt FROM dwd.flight_flt_fact fact JOIN dim.flight_info dim ON fact.flight_id dim.flight_id WHERE dim.flight_date 2024-09-30 GROUP BY dim.flight_date, dim.flight_no;从校验结果看中台公共层的旅客数要能和离港系统的值机数对得上行李数要和行李分拣系统的数据对得上。对不上的原因一般出现在同步链路延迟和公共层去重逻辑上直接用SQL按天、按航班查定位很快。这个SQL看起来简单却是中台数据质量的最后一道防线比看一堆数据质量报告管用。5.2 用 WHY、WHAT、HOW 校准项目方向南航在PPT最后抛出三个问题为什么要数字化转型数字化转型转什么如何实现数字化转型这个框架适合在任何中台项目卡壳时拿出来重新对齐。WHY对应价值判断说不清楚为什么做项目大概率做不成WHAT对应建设内容明确转什么才不会把中台做成技术堆料HOW对应实现路径回答怎么做落到组织和流程上。后台遇到最多的情况是团队陷在HOW层面出不来天天讨论用什么组件、怎么分服务连WHY都没对齐。所以从那以后我每次接手双中台项目开工前强制要求业务方和技术方坐在一起先用一页纸把WHY和WHAT写清楚再进入技术方案评审。这一步看起来慢省下来的返工时间却最多。希望帮到你。本文还有配套的精品资源点击获取 南航双中台实践：业务中台与数据中台如何驱动数字化转型
简介《中国南方航空数字化和双中台方案》演示文稿源自南航数字化转型一线实践聚焦智慧城市、大数据、互联网与人工智能应用场景面向企业数字化负责人、中台架构师及相关技术人员解决传统信息化建设中重复造轮子、响应慢、数据壁垒高等痛点。包内仅1个pptx文件大小约1.1MB轻量便携便于直接用于内部研讨或方案借鉴。目前已有98人学习。内容系统梳理了南航数字化管办分离体系、创新机制含科学技术委员会、人工智能重点实验室、五小创新等、流程管理、人才培养并拆解双中台落地细节业务中台以航班中心整合航班全流程数据为营销、机务等系统提供标准化模块服务数据中台通过《大兴机场转场通告》等案例展示报表快速响应业务人员借助自助分析工具可在2小时完成仪表板、1天完成数据门户。整体兼顾顶层设计与执行方法对智慧城市、大数据、人工智能相关从业者具有实用参考价值。1. 南航双中台方案为什么中台在航司比在互联网公司更好讲做数字化转型的人多少都有这种体会中台这个词被互联网公司讲烂了落到传统行业却常常水土不服。中国南方航空的数字化和双中台方案是少有的把中台讲得比互联网公司还实在的一份材料——它不堆技术名词而是把中台定位成“解决慢和贵问题的企业级能力复用平台”用航班中心整合全生命周期数据用数据中台把报表交付周期从一个月压到一天。这份PPT值得反复读的不是几张架构图而是它把组织、流程、人才和两个中台绑在一起讲透了。适合正在做数字化转型规划、中台建设立项或者被报表需求压得喘不过气的数据团队仔细看。2. 业务中台与数据中台航班中心怎么把全生命周期数据变成可复用能力2.1 中台的定位先解决“慢”和“贵”再谈技术平台南航对中台的定义很克制把可复用的功能或能力进行标准化、模块化管理是企业级能力复用平台通过减少“重复造轮子”解决“慢”和“贵”的问题。这句话信息量很大。传统航司信息化建设往往是项目制今天营销部门建一个航班查询接口明天机务部门又建一个后天地服部门再建一个接口越堆越多维护成本越来越高这就是典型的“慢”和“贵”。中台要做的事情是把这些重复能力收编、标准化变成企业级服务。南航特别强调中台更是理念、是架构是企业内部全体组织利用平台化手段发现、沉淀与复用企业级能力的过程。这句话的意思是不要指望上一个中台平台就万事大吉组织里的人愿不愿意把能力沉淀到中台、愿不愿意复用别人的能力才是中台能不能转起来的核心。在航司做中台比互联网公司更合适的原因在于航司的业务域高度集中核心就是航班围绕航班衍生出营销、机务、地服、空勤、货运这些系统。航班全生命周期数据的边界是清晰的天然适合做能力复用。这比互联网公司那种业务边界模糊、组织调整频繁的环境要友好得多。2.2 业务中台航班中心的四种服务形态南航业务中台以航班中心为核心整合航班全生命流程数据为全公司各业务系统提供服务。服务形态有四种PPT里把它归纳为服务形态说明典型场景标准化所有系统按同一套接口规范调用不因业务部门差异而变化航班时刻查询、航班状态同步定制化在标准服务基础上按需扩展字段或逻辑满足特定系统要求机务维修计划对航班动态的定制视图共享化一个服务被多个业务系统同时复用避免重复建设航班动态推送、旅客行程关联模块化把复杂业务拆成可组装的服务单元按需组合值机、行李、配载、登机服务组合航班中心把这些服务注册到企业级运行协作平台上营销系统、机务系统、地服系统、空勤系统、货运系统都通过平台调用不再各自建一套。这样系统之间的耦合度降下来了新业务上线时只需要组装已有服务不需要从零开始。2.3 业务中台落地四步走和两个关键参数航班中心的建设思路可以拆成四步做业务中台规划时可以照这个顺序走梳理航班全生命周期阶段从航班计划、座位销售、值机登机到飞行运行、维修保障画出完整流程地图。圈定各阶段里的共性能力比如航班状态变更、旅客信息同步、舱位库存查询这些是高频复用的部分。定义服务契约明确接口字段、调用方式、权限边界这一步决定服务能不能被其他系统顺畅接走。把服务部署到企业级运行协作平台上带着调用方的反馈持续迭代服务版本。两个关键参数值得盯一是服务复用率也就是多个业务系统在用的服务占全部已发布服务的比例低于三成说明拆出来的大量服务没有被复用属于自嗨二是服务响应时间航班运行是实时场景航班状态推送类服务要求在秒级以内超过这个标准就要考虑是不是服务拆得太细导致链路变长。航班中心还有一个容易被忽略的设计数据反馈。各业务系统调用服务后产生的业务数据要回写到航班中心形成完整的数据闭环。没有这个闭环业务中台只是接口网关不是能力平台。2.4 数据中台公共层先行报表交付从“按月”到“按天”数据中台的典型成果是《大兴机场转场通告》这个需求。时间线拉出来非常直观时间动作9月28日AOC运行控制中心提出报表分析需求9月28日数据团队评估数据中台公共层已具备数据条件9月29日BI报表开发、数据验证、投入使用9月30日报表正式交付给业务使用三天交付一张报表在过去是不可想象的。传统做法是业务提需求数据团队排期ETL开发两周报表开发一周测试验证一周一个月就过去了。南航能三天交付核心原因是公共层已经提前准备好了——这就是数据中台和传统数仓最大的区别。数据中台的分层逻辑大致是这样贴源层原样接入各业务系统的原始数据保留全部细节用于追溯。公共层把跨系统共用的数据统一口径、统一清洗形成企业级的数据资产这是去重的核心。应用层面向具体报表和应用场景生成数据比如大兴机场转场航班运行分析直接基于公共层聚合。公共层建得好不好决定了报表需求能不能快速响应。南航数据中台评估公共层已具备数据条件意味着航班、旅客、运行这些核心数据已经标准化不需要每次从头做数据清洗。2.5 数据中台自助分析把报表能力交还给业务数据中台建设到后期南航开始鼓励业务人员自助分析。借助数据中台的数据资源配合QuickBI工具经过培训的业务人员可以在2小时内完成仪表板搭建1天内完成数据门户开发。这个效率提升的背后是公共层数据已经足够干净、口径统一业务人员不需要懂SQL也能拖拽出分析页面。这里有一个选型逻辑QuickBI这类BI工具要发挥作用前置条件是公共层数据的维度、指标已经定义好。很多团队买了BI工具却用不起来就是因为底层数据一团乱麻业务人员拖出来的数对不上自然不信。南航的做法是先花力气做公共层再推自助分析顺序不能反。自助分析还有一个隐性好处把数据团队从低价值的取数工作中解放出来。过去业务要一张报表数据团队要排期开发现在业务自己就能搭仪表板数据团队只需要在公共层和指标层做维护。这样数据团队才有精力去做更深入的数据挖掘和业务分析而不是整天写SQL。3. 数字化转型体系管办分离、创新机制、流程管理、人才梯队四张牌3.1 管办分离科信部管“建什么”信息中心管“怎么建”南航数字化管理体系的骨架是“管办分离”原则三个角色权责切得很清楚角色职责对应问题科技信息与流程管理部科信部投资决策、项目评价建什么信息中心建设实施、信息化基础设施、网络安全怎么建业务部门需求提出为什么要建这个分工看着简单实际执行中很容易走样。最常见的问题是科信部把项目批了之后就不管了等系统上线了才发现业务根本不用或者是信息中心既当运动员又当裁判员自己给自己批项目自己验收。南航把项目评价放在科信部建设实施放在信息中心需求提出放在业务部门等于给每个环节都上了约束——项目做得好不好不是建设方自己说了算。这套机制对双中台建设尤其重要。中台项目投入大、周期长、收益不直观如果没有管办分离很可能出现信息中心闷头建了一年业务部门根本不认的情况。科信部管投资决策意味着中台项目立项时就必须回答业务价值的问题这倒逼建设过程始终以业务需求为导向。3.2 创新体系从五小创新到人工智能重点实验室南航的创新体系分三层顶层是科学技术委员会中间是民航维修工程技术研究中心、民航航空公司人工智能重点实验室这类专业平台基层是明珠创新工作室和“五小创新”小发明、小革新、小改造、小设计、小建议。这套体系的厉害之处在于覆盖了从战略研究方向到一线员工微创新的全链条。民航维修工程技术研究中心和人工智能重点实验室是由南航与中国民航大学共建的已被民航局正式认定并挂牌。这种产学研结合的模式解决的是企业自建研发团队的短板——高校提供理论研究和人才储备企业提供业务场景和数据成果直接落地到维修工程和航空运行场景中。对于做中台的人来说创新体系还有一个实际价值它是双中台的需求输入源和创新产品的孵化器。五小创新看似不起眼但一线员工提出的改善建议往往是最贴近业务的。比如值机员发现某个操作路径太繁琐机务工程师觉得维修记录录入效率低这些反馈经过明珠创新工作室筛选后可能会变成业务中台上的一个小服务也可能成为数据中台的一个分析主题。创新体系和中台形成正循环创新产生需求中台承载需求能力沉淀后反哺更多创新。3.3 流程管理体系用技术固化流程而不是靠制度文件南航成立了企业架构与流程管理委员会来统筹这件事核心动作是梳理公司流程架构、优化业务级流程然后通过技术手段固化业务流程。流程如果只停留在制度文件层面执行起来就会走样只有固化到信息系统里才真正算数——这也是企业架构和流程管理对双中台最实际的价值。流程管理落到执行层面遵循的是“流程绩效运用”这个抓手梳理出来的流程要能衡量绩效比如值机流程的平均耗时、航班延误时的应急响应流程流程绩效数据从哪里来从数据中台来。流程绩效运用包括流程管理与激励制度体系挂钩流程优化做得好不好直接影响到部门绩效评估。这里面有一个很多企业容易搞反的地方先画流程再上系统而不是先看系统能力再定流程。南航的做法是流程梳理和优化业务级流程在前通过技术固化业务流程序在后先想清楚业务应该怎么跑再让IT系统去支撑。中台项目如果跳过流程梳理直接上系统等于把原来的低效流程自动化结果只会更糟。3.4 人才培养从人才画像到选育用留的全生命周期管理南航的人才体系把数字化人才作为独立的人才类别来管理打通了“选育用留”全链路环节关键动作核心产出人才定位明确复合型数字化人才标准区分技术型、业务型、复合型人才画像筛选入库从现有员工中筛选具备数字化潜质的人员进入人才库梯队库池培养管理按全生命周期制定培养计划轮岗、项目锻炼、专业培训培养方案考核出库定期人才盘点考核合格者出库进入关键岗位不合格者继续培养人才盘点报告价值创造通过岗位任用、项目负责、创新激励实现价值兑现人才激励体系数字化人才画像这个工具值得细说。很多人力资源部门做人才画像容易做成“学历证书”的简单标签南航强调的价值在于把画像落到具体维度上技术宽度懂不懂数据、懂不懂系统架构、业务理解懂不懂航班运行、维修、营销这些业务场景、数据能力能不能用数据工具做分析、项目管理能力能不能推动跨部门协作。这些维度的数据从哪里来数字化人才库本身就是在数据中台上做的人才盘点技术手段和业务场景在这里完美闭环。复合型数字化人才梯队库池这个设计本质上是在企业中建一个内部人才市场。各业务部门有数字化项目需求时可以直接从中台人才库找人项目结束后人才回到库池。这样既锻炼了人才又保证了数字化项目有懂业务又懂技术的人来主导避免了业务部门和技术部门互相听不懂话的尴尬。4. 双中台落地常见问题5条踩坑记录与排查路径4.1 现象报表需求排了一个多月业务等部门等得失去耐心原因数据团队接到需求后才开始从贴源层找数据、清洗数据、开发报表公共层根本没有覆盖这个业务域。数据中台如果只建了贴源层没有沉淀好公共层每一次报表需求都是一次全新项目一个月的排期是必然结果。解决把公共层覆盖率当成数据中台的第一KPI来管在数据中台建设期先盘点高频报表依赖的公共数据实体按航班、旅客、销售、运行这几个域优先补齐公共层。业务侧提交报表需求时按“评估公共层是否已具备条件”作为第一步来走公共层已有的直接排期到小时级交付公共层缺失的走数据资产补充流程建设周期另算。4.2 现象业务中台上线后接口调用越来越乱部分系统绕过中台直连数据源原因业务系统觉得中台服务满足不了特定需求或者嫌走中台多一跳响应慢又改回直连数据库的老路。中台服务如果不够标准、不够好用业务系统宁可走回头路这其实不是业务系统的问题是中台治理机制没建立起来。解决把企业级运行协作平台变成唯一的数据通道从网络层面和账号权限层面收紧对数据源直连的管控。用服务调用审计日志来看绕过行为这是中台运维要盯的第一个指标服务发布时必须带调用方认证数据源侧不对业务系统开放直连账号。中台团队要定期review服务调用量调用量很低或者被绕过的服务要么是服务设计有问题要么是业务侧没有迁移过来都要专项处理。4.3 现象业务人员用QuickBI拖出来的仪表板数据和报表团队开发的对不上原因指标口径口径不统一是常见问题。比如“航班准点率”这个指标运行部门按航班关门时间计算营销部门按起飞时间计算两边数对不上很正常。数据中台把数据统一收集了但指标定义没有统一等于中台把数据汇聚到了一起却没有把口径拉平业务自助分析自然翻车。解决建立企业级指标字典每个指标指定一个口径owner所有报表和自助分析都从指标字典引用口径定义。第一时间把公共层存量的指标全部梳理出来逐一定义计算逻辑和维度的约定再把这个指标字典嵌入到BI工具里。业务人员新建仪表板时看到他选用的指标的计算口径说明让整个过程的透明度更高、更便于理解报表团队和自助分析用同一套口径数对不上这个问题基本绝迹。4.4 现象数据中台只有IT在推业务部门到了验收阶段才开始提意见原因数据中台建设期把业务部门当成最终用户而不是共建方业务部门没有深度参与建什么、怎么建只在最终验收时被动看效果。这也提醒我们数据中台如果只被IT部门抱着业务价值就说不清验收时很难获得业务认可。解决让业务部门直接参与公共层的指标定义和优先级排序。在数据中台项目初期按业务域划分专题小组由业务骨干担任数据产品经理角色对公共层的数据质量、指标口径、分析场景负责。培养业务人员自助分析能力让会用的业务人员在各自部门产生示范效应是最有效的中台推广方式。4.5 现象中台项目上线即巅峰半年后服务没人维护数据没人更新原因中台没有运营责任主体。项目团队成员在验收后回到了原来部门中台服务发现问题找不到人修数据质量问题没人认领中台快速腐化。中台是一个需要长期运营的能力平台不是一个交付完就结束的项目。解决在立项时就把中台运营团队编制明确下来日常运营至少覆盖服务治理、数据质量、指标维护三个角色。服务上线时必须登记ownerowner对服务生命周期负责数据质量建立月度巡检机制数据更新延迟超过阈值要自动告警。把中台的复用率、报表交付周期、数据质量这些指标纳入运营团队绩效考核中台才不会验收即结束。5. 验证中台有没有用用一个报表需求走完整个闭环5.1 六步闭环验证法中台项目最怕说不清价值。我把PPT里的逻辑结合实操经验整理成一个六步闭环验证法每接一个中台项目就照这个走一遍挑需求选一个业务价值明确、跨系统取数、过去响应周期超过两周的报表需求。查底座直接看数据中台公共层有没有覆盖报表涉及的核心数据实体先看表和指标的覆盖情况再看更新时效。定口径和业务确认指标计算逻辑看是否已存在于指标字典没有就先补建。快交付交付过程用BI工具完成先看是否能快速出雏形优先复用已有公共层模型。交叉验证拿报表结果和业务系统的原始台账做比对验证数据链路正确性。复盘沉淀评估这个需求复用了哪些中台服务沉淀了什么新的数据资产可复用到同类需求。第5步的交叉验证是关键用的SQL逻辑很直接-- 抽查校验报表口径把中台公共层结果与业务系统台账汇总做对比 SELECT dim.flight_date, dim.flight_no, SUM(fact.passenger_cnt) AS pax_cnt, SUM(fact.luggage_cnt) AS luggage_cnt FROM dwd.flight_flt_fact fact JOIN dim.flight_info dim ON fact.flight_id dim.flight_id WHERE dim.flight_date 2024-09-30 GROUP BY dim.flight_date, dim.flight_no;从校验结果看中台公共层的旅客数要能和离港系统的值机数对得上行李数要和行李分拣系统的数据对得上。对不上的原因一般出现在同步链路延迟和公共层去重逻辑上直接用SQL按天、按航班查定位很快。这个SQL看起来简单却是中台数据质量的最后一道防线比看一堆数据质量报告管用。5.2 用 WHY、WHAT、HOW 校准项目方向南航在PPT最后抛出三个问题为什么要数字化转型数字化转型转什么如何实现数字化转型这个框架适合在任何中台项目卡壳时拿出来重新对齐。WHY对应价值判断说不清楚为什么做项目大概率做不成WHAT对应建设内容明确转什么才不会把中台做成技术堆料HOW对应实现路径回答怎么做落到组织和流程上。后台遇到最多的情况是团队陷在HOW层面出不来天天讨论用什么组件、怎么分服务连WHY都没对齐。所以从那以后我每次接手双中台项目开工前强制要求业务方和技术方坐在一起先用一页纸把WHY和WHAT写清楚再进入技术方案评审。这一步看起来慢省下来的返工时间却最多。希望帮到你。本文还有配套的精品资源点击获取