南航数字化双中台方案：管办分离与企业级能力复用落地指南

简介一份聚焦中国南方航空数字化与双中台建设的分享PPT面向企业数字化转型负责人、中台架构师及大数据从业者解答“为何转、转什么、如何转”三大核心问题。压缩包内仅1个pptx文件大小约1.1MB内容紧凑精炼。目前已有98人浏览学习。方案清晰梳理了南航数字化管办体系、创新体系、流程管理及人才培养机制并重点展开双中台实践以航班中心为业务中台核心整合航班全生命周期数据为营销、机务、地服等系统提供标准化共享服务数据中台则通过《大兴机场转场通告》分析等案例演示报表快速响应与业务人员自助分析能力体现打破数据壁垒、激发业务活力的落地价值。适合希望借鉴大型航空集团数字化转型路径的读者快速了解整体框架与典型应用场景。1. 南航数字化双中台一份能直接抄的企业级转型方案数字化转型最棘手的一种局面是业务部门提需求、IT排期排到一个月后而营销、机务、货运系统又各自维护着一份航班数据。南航这套《数字化和双中台方案》恰恰从这两个痛点切入把“为什么转、转什么、怎么转”拆成了组织架构和中台架构两层落地路径。它不把中台讲成技术平台而是讲成企业级能力复用平台用航班中心和BI报表两条链路说明白“慢”与“贵”如何被解决。适合数字化负责人、企业架构师、中台产品经理以及所有想从真实方案里抄作业又怕踩坑的人。方案里真正值钱的不是中台这个概念而是“管办分离”的组织设计。它让南航能把数字化投资的决策权、建设权和需求权分开避免重复造轮子。本文按“概况→双中台→避坑→复用”的顺序把这份方案还原成可以落地执行的动作。2. 数字化概况背后的组织逻辑管办分离与四套驱动体系南航的数字化概况部分看似在罗列成绩其实在讲一套组织逻辑。它把数字化建设拆成了“管理”和“办事”两条线管办分离明确谁决策、谁建设、谁提需求创新、流程、人才三套体系负责让数字化持续产生价值。这层组织逻辑比具体技术选型更值得先读懂。2.1 管办分离把“建什么、怎么建、提什么需求”拆给三个角色先看原理。南航的管办体系遵循“管办分离”原则科技信息与流程管理部科信部负责投资决策和项目评价解决“建什么”信息中心负责建设实施解决“怎么建”业务部门负责需求提出。同时由信息中心统筹全公司网络安全和信息化基础设施。为什么这样拆因为传统模式下同一个部门既管立项又管建设容易出现两个问题一是自己批自己项目该不该做没人把关二是建设团队被业务直接拉走长期给某条业务线做外包沉淀不了企业级能力。管办分离在决策者和建设者之间加了一道隔离项目立项时要面对业务价值的追问建设过程中也能保持技术方案的主导权。落到实施我一般会按四步走。第一步盘点当前角色。把现在所有信息化项目的立项审批人、项目执行人、需求提出人分别列出来找出“既是运动员又是裁判员”的岗位。第二步建立立项评审节点。哪怕科信部和信息中心暂时在同一个部门也要在项目启动前增加一个评审环节由不参与建设的人签字确认“这个项目值得做、预算上限是多少”。第三步定义需求接口规范。业务部门不能直接跨过信息中心找外包写系统需求必须进入统一入口由科信部做初步筛选。第四步加上项目后评价。交付半年后评估实际使用率、性能指标、业务价值评价结果反哺下一次立项。角色分工可以参考这张表角色核心职责边界提醒科信部投资决策、项目评价决定“建什么”不介入具体技术选型只审目标和预算信息中心建设实施决定“怎么建”统筹网络与基础设施不替业务部门承诺需求范围只对交付负责业务部门需求提出不能绕过立项直接联系研发或外包这里最常被忽视的是“项目评价”。南航在管办体系里明确写了科信部负责项目评价目的是让所有在建系统在交付后还能被回头看。我见过很多企业做了管办分离但评价只走流程最后系统上线三年没人用照样不扣任何人的绩效。评价一定要跟预算和后续运维挂钩才有人认真对待。2.2 四套驱动体系创新、流程、人才、管理怎么同时转数字化建设不光是IT部门的事。南航的数字化概况里同时出现了四套体系数字化管办体系、数字化创新体系、数字化流程管理体系、数字化人才培养体系。这四套体系分别回答了四个问题事情怎么定、新技术哪里来、流程怎么固化、人从哪里来。用一张表把它们的关系列清楚体系关键实体解决的问题管办体系科信部、信息中心、业务部门数字化项目谁来定、谁来建创新体系科学技术委员会、民航维修工程技术研究中心、人工智能重点实验室、明珠创新工作室、五小创新新技术从哪里孵化流程管理体系企业架构与流程管理委员会、科信部、业务部门、信息中心流程怎么梳理和固化人才培养体系数字化人才梯队库池、人才画像、选育用留谁来支撑长期运营创新体系值得细说。南航的做法是行业级平台共建和基层创新并行南航与中国民航大学共建民航维修工程技术研究中心和民航航空公司人工智能重点实验室被民航局正式认定挂牌。这相当于把高校的研发能力直接挂到企业里解决企业自建研发团队成本高、周期长的问题。明珠创新工作室和“五小创新”小发明、小革新、小改造、小设计、小建议解决一线问题让维修、运控这些懂业务的人也能贡献改进。这两个方向一个向上借力一个向下挖潜中间的科学技术委员会负责把点子筛成项目。流程管理体系的做法是“梳理—优化—固化—绩效”四步先梳理公司流程架构和业务级流程再结合信息化实施流程找出能合并、能删减的环节然后通过技术手段把流程固化到系统里最后用流程绩效和激励制度让流程真正跑起来。这里的关键动作是培养流程管理人才没有人的流程文档最后都会变成纸面流程。南航特意提到流程文化和流程型组织意思就是流程管理不是流程管理部一个部门的事每个业务负责人都要承担流程Owner的角色。人才培养体系可以按“选育用留”来理解。选是根据人才定位筛选入库建立复合型数字化人才梯队库池育是全生命周期培养管理按管理方法和技术方向分别培养用是通过人才盘点和数字化人才画像把合适的人放到关键项目上留是用价值创造、人才激励和职业发展让人才留下来。这套做法的核心是先把人才当资产来盘点而不是等项目来了再去招。对这四套体系我给企业的自检清单是有没有一个委员会级别的数字化决策实体而不是只靠IT部门自己拍板有没有外部技术研究合作机制科技成果是不是只停留在论文层面流程管理有没有落地到系统固化业务流程图和实际系统操作是否一致数字化人才有没有画像和梯队库池关键项目上是不是永远只有一两个人会干以上四问如果都是否说明组织基础还没到位这时候沿用南航这套方案就容易水土不服。提示管办分离和四套体系都属于组织级前置条件比任何中台技术方案都先动。组织不定建出来的中台一定是空壳。3. 转型三问WHY、WHAT、HOW在双中台里怎么落地南航的PPT里放了三个问题WHY、WHAT、HOW。这其实是很多企业做数字化转型时被问倒的三个问题为什么要转转什么怎么转双中台方案就是对这三个问题的回答之所以转是因为慢和贵转的是把可复用能力沉淀成企业级平台怎么转是先用业务中台建能力、再用数据中台释放数据价值。3.1 WHY从“慢”和“贵”两个痛点推导转型必要性方案里给中台的定位是“通过减少重复造轮子解决慢和贵的问题”。这里有一个容易被忽略的判断数字化转型的必要性不需要上升到战略层面的宏大叙事只需要算清时效、算钱、算等待周期的账就行。传统信息化建设的典型场景是每个业务系统各自为政。营销系统要一份航班列表建一张航班表机务系统要一份航班列表再建一张地服系统需求差不多又建一张。三张表结构相似但字段口径不一样今天改一个航班时刻三个系统要跟着改三遍这叫“慢”。每一遍都要人力开发、都要运维保障、都要数据校验三张表的建设成本和维护成本翻了三倍这叫“贵”。互联网时代业务变化又加快慢和贵的代价被放大转型就不是可选项了。这里顺带回应一下大数据和人工智能的角色大数据分析、AI模型都要建立在干净、统一的数据底座上。南航即便不建设数据中台报表分析、智能决策、机器学习这类应用也会被脏数据和口径不一致卡住。双中台把数据底座打好了AI才有用武之地。换句话说双中台是数据智能的“前置条件”不是追热点。3.2 WHAT业务中台数据中台转的是企业级能力复用平台南航对中台的定义值得逐句拆解“把可复用的功能或能力进行标准化、模块化管理是企业级能力复用平台”。注意关键词的顺序先是“可复用的功能或能力”然后是“标准化、模块化”最后才是“企业级能力复用平台”。它同时强调中台是理念、是架构是企业内部全体组织利用平台化手段发现、沉淀与复用企业级能力的过程。把这段话拆开看有三层意思。第一层中台不是某个系统。它不是一个可以打包购买的软件产品而是一套治理机制。即便落到技术层面是业务中台和数据中台前面的“理念、架构、过程”决定了光买软件学不来中台。第二层中台管理的对象是“功能或能力”。能力要能被复用得先被标准化成服务接口再模块化组装。比如航班中心把航班动态做成了一个服务营销系统要航班动态调接口机务系统要航班动态也调接口。这才叫复用。第三层中台必须是“企业级”的。如果只为一个业务部门服务那不叫中台叫业务系统的公共组件。企业级意味着要有全公司层面的归属和治理这也是为什么南航把科技信息与流程管理部、信息中心放在同一套管办体系里来支撑中台建设。为了说清楚传统模式和中台模式的差别可以做一张对比表维度烟囱式建设中台式建设能力建设每个系统独立实现公共能力下沉到业务中台数据使用数据散落在各系统数据统一整合到数据中台需求响应排期以周/月计报表以天/小时计团队协作业务系统之间点对点协同通过服务契约和能力地图协同落到WHAT层面转的就是从“系统建设”转向“能力建设”。这是很多企业转型转了大半年还在原地打转的原因项目名还没换立项思维还是按系统立。3.3 HOW从航班中心和BI报表看落地路径从南航的实践看HOW的答案不是从顶层设计全面铺开而是找两个切入点业务中台先用航班中心破局数据中台先用报表需求破局。这是非常符合现实的选择因为航班数据是民航业务的主线所有系统和部门都绕不开它报表需求则是所有业务部门高频、可量化、见效快的痛点。常见做法可以总结为五步。第一步选定一个高频业务域。对南航来说就是航班全生命周期。对一般企业可以选客户、订单、商品等。判断标准这个域是否被多个业务系统共用是否自带明确的上下游流程。第二步梳理共享能力清单。把高频业务域里可复用的业务动作列出来比如“查询航班动态”“校验前后舱单”“获取机组成员”。注意清单要由业务人员和技术人员一起做避免只从接口层面硬拆服务。第三步技术侧做标准化封装。把能力做成微服务定义好入参、出参、版本、错误码放到企业级运行协作平台上统一管理。这一步会涉及微服务运行系统的建设但更重要的是定服务契约。第四步推动存量业务系统接入。老系统不可能一次性改造完。常见做法是让新需求都通过中台拿数据存量接口逐步迁移给一个过渡期不要追求“大替换”。第五步建立数据反馈。业务系统用了中台的服务产生的数据要回流到数据中台反过来验证服务质量和数据完整性形成正循环。这五步和南航方案里“数据整合创造价值→业务系统→数据反馈”的闭环是吻合的。只要其中一步断了双中台就会退化成两个孤岛系统。4. 双中台建设核心航班中心与数据中台的自助分析链路双中台的价值不在概念而在两条具体的建设链路业务中台的航班中心和数据中台的报表与自助分析。航班中心解决的是“数据和服务怎么共享”数据中台解决的是“业务人员怎么能更快拿到数据”。这两条链路是整份方案里最能落地参考的部分。4.1 业务中台航班中心怎么把全生命流程数据变成共享服务航班中心是南航业务中台的核心。它整合的是“航班全生命流程数据”服务对象包括营销系统、机务系统、地服系统、空勤系统、货运系统等。支撑形态是微服务运行系统和企业级运行协作平台。所谓全生命周期是指航班从航班计划、运力安排、旅客销售、运行控制、地面保障到维修放行、机组排班、货运装卸完整的业务链路。这些环节过去分散在不同系统里由各系统各自维护航班状态状态不一致的现场很常见。航班中心把这些数据按统一模型整合再以服务化方式输出就相当于把“航班”这个企业级主数据变成了所有系统共享的标准资源。服务化拆分可以这样梳理服务域典型能力消费方航班计划查询班期时刻、发布航班变更营销、地服运行控制航班动态、延误原因、改航信息AOC、地服、空勤地面保障机位分配、旅客人数、行李装载地服、货运维修放行维修状态、放行结论、可用性机务、运控空勤排班机组人员信息、执勤期、资质空勤、运控这张表的意义在于每个服务能力都对应一个或多个业务消费方。当一个服务被多个系统调用复用的价值就体现出来了。比如“查询航班动态”营销要看地服要调度货运要配载与其每个系统各建一次不如由航班中心统一提供保证数据口径一致。落地的时候我的建议是先不要追求把航班中心建得包罗万象。先选一个业务迫切、跨系统调用频繁的能力比如航班动态查询做成标准服务让三个以上系统接入。接入过程中暴露出的数据口径和字段冲突就是航班中心要继续完善的方向。4.2 数据中台一个转场报表在三天内从需求到交付的链路南航数据中台最打动我的是大兴机场转场通告的案例。它用三天时间9月28日到9月30日完成了从AOC提出分析需求到报表交付投入使用的完整链路。把三天的动作拆开第一天9月28日AOC提出航班运行分析需求数据中台团队评估公共层数据条件。评估结论是公共层已具备数据条件于是直接进入开发流程。第二天9月29日BI报表开发同时做数据验证。数据验证重点是核对口径是否与AOC关注指标一致比如航班正常率、延误时长、转场航班量等。第三天9月30日报表交付并投入使用。这个三天交付的前提是第一天就“评估数据中台公共层已具备数据条件”。换句话说数据中台的功夫不是在需求到达之后花的而是在需求到达之前就把公共层建好了。公共层就是大数据体系里的公共数据模型层通俗讲就是把原始数据清洗、整合、建模成可以直接用于分析的宽表。我一般会建议企业把“公共层数据条件”做成一张可打分的评估表评估项说明通过标准主题域覆盖本次需求涉及的主题域是否已建模相关表和字段已入公共层主数据一致航班号、日期、飞机号等主键是否统一多系统关联可以用统一主键调度完整性公共层任务是否按日/实时调度没有迟到黑洞指标数据当天可查权限就绪业务角色是否已开通对应数据集权限无需临时走审批流程四项全绿才能承诺“三天交付”。这四项里最容易翻车的是主数据一致。如果营销系统的航班号口径和运控系统的不一样关联出来的航班正常率就是错的报表开发完还得花时间返工。4.3 自助分析QuickBI 培训让业务人员2小时搭仪表板数据中台建设到一定程度瓶颈就不在IT开发能力而在业务人员对数据的使用方式。南航的做法是用数据中台的数据资源加QuickBI工具对业务人员进行培训让他们自己分析。效果数据非常直观2小时内完成仪表板搭建1天内完成数据门户开发。而以前同样的需求从提需求到报表上线要1个多月。这一段要做个对比维度IT开发报表业务人员自助分析交付周期1周-1个月2小时-1天数据范围按指定口径取数公共层宽表自助筛选适用场景结算、对账、审计等强口径需求日常监控、探索分析、活动分析团队依赖依赖IT排期依赖培训质量和授权范围自助分析要能跑起来有几个前提。第一数据资源必须是被加工好的公共层宽表而不是裸的明细库业务人员不需要写复杂SQL也不需要了解底层表结构。第二QuickBI这类工具要支持拖拽式做表常见图表类型要齐全。第三培训不能只教按钮要对业务场景设计课程比如地服看航班正常率、营销看客座率每人只学自己需要的模块。第四要有口径字典避免业务人员对指标定义理解不一致。这里要特别提醒一个边界2小时做仪表板的能力不等于所有报表都能自助。财务结算、审计追溯这类对数据准确性和流程有硬性要求的报表还是应该走IT交付。自助分析的价值在于释放日常运营监控的报表需求把IT的人力留出来做更复杂的事。5. 双中台资源复用避坑四个常见误判与排查路径中台建设这两年最大的问题是概念大家都会讲落地到处都是坑。我把这份方案里最容易误读的地方和常见的翻车场景整理一遍按“现象→原因→解决”来写帮大家在对照落地的时有个预警。5.1 误判一把中台当系统采购买回来没人接现象企业采购了中台产品但原有的业务系统并不接。数据没有进来接口没有调用中台变成了一个昂贵的空壳。最后连算力的钱都省不回来。原因把中台理解成了技术平台产品忽略南航定义里的第一部分——“把可复用的功能或能力进行标准化、模块化管理是企业级能力复用平台”。“能力”和“标准化”是前提产品只是承载工具。如果企业没有先做能力盘点没有梳理出哪些业务能力值得下沉买回来的中台就没有可复用的对象。另一个常见原因是组织上没有设定“新项目必须通过中台获得能力”的红线。解决先做能力盘点再谈产品选型。盘点方法可以这样把核心业务域的流程清单拉出来标注每个“活动”是否被多个部门使用、是否每个系统都重复实现过。对符合这两个条件的能力列入中台建设优先级。对于已经买入的产品强制从新建项目开始接入设定接口对接率指标按月通报。没有这两个动作中台必然沦为展示系统。5.2 误判二管办分离变成三不管现象科信部负责决策、信息中心负责建设、业务部门负责提需求看上去责权分明实际运行时需求迟迟没人拍板项目延期后业务说“这不是我要的”信息中心说“我按需求文档做的”科信部说“我只看结果”。原因“管办分离”只在组织架构上做了拆分但三个角色的协作规则没细化。最核心的“需求边界确认”环节缺失导致业务部门提出需求时没有签承诺信息中心开发时没有验收标准科信部评价时没有数据支撑。本质上不是分离的问题是决策和责任没绑在一起的问题。解决在项目立项书里增加三个签字区业务部门签字确认需求边界和目标信息中心签字确认技术方案和交付承诺科信部签字确认预算上限和评价指标。项目验收时按签字内容逐项核对不达标不允许结项。这样“管办分离”就从物理拆分变成了责任闭环。5.3 误判三数据中台公共层没评估就接需求现象学了大兴机场三天交付的案例回去也承诺“三天出报表”结果报表需求来了以后开发先去清洗半个月的数据最后交付周期还是一个月。原因没有消化案例里最关键的一步——第一天先“评估数据中台公共层已具备数据条件”。三天交付的前提是公共层早就把数据准备好了。如果公共层还没建好第一天的评估结论就是“不具备条件”那么接下来要做的不是承诺三天而是先建公共层。承诺“三天交付”却不评估公共层是把因果关系搞反了。解决建立“公共层成熟度评估”机制。在接收报表需求时先回答四个问题需求涉及的主题域有没有建表主数据口径是否统一数据调度是否能保证当天数据可用权限是否已提前开好四个问题都通过才走快速交付流水线任一项不通过先排公共层建设任务再进报表开发。这样表面上啰嗦了一点但实际交付周期反而会更短。5.4 误判四自助分析给所有业务人员开数据库权限现象把QuickBI权限全放开业务人员什么都可查结果指标口径打架、报表可信度下降有人用工具跑大范围明细查询把数据中台集群负载跑满影响线上业务。原因自助分析的前提是数据中台把公共层宽表和数据集做好业务人员只面对“加工后的”数据。直接开数据库权限等于让业务人员面对原始明细表既不懂口径也不懂查询优化翻车是必然的。南航培训业务人员2小时做仪表板说的是“借助数据中台的数据资源”和QuickBI工具没有说过把原始库交出去。解决用“数据集”方式开放数据而不是开放底层表。在QuickBI这类BI工具里由数据团队提前制备数据集每个数据集预先定义维度和指标口径、关联关系、可查询范围。业务人员只能从数据集里选字段看不到底层物理表。同时把口径说明挂到元数据上。至于大查询问题用限流和队列控制跑数等级保证核心业务不受影响。注意中台建设的每个坑根源几乎都在“组织治理”和“数据基础”上。技术选型反而是最不容易出错的一环。6. 把这份PPT变成你自己的中台规划验证清单与汇报技巧读一份方案最难的不是看懂它写的内容而是把它翻译成自己企业能用的动作。最后这部分我讲两个最实用的落地点怎么验证中台建设有没有用怎么跟领导汇报时不跑偏。先给验证维度。中台建得成不成功不看你有多少个微服务也不看PPT画得多好看就看三个指标需求交付周期服务复用次数重复投入成本。周期从月缩短到天级别说明数据中台在起作用一个航班数据服务被营销、机务、地服三个以上系统调用说明业务中台在起作用重复建设预算明显下降说明整个双中台机制在起作用。这三项里面我最推荐盯“服务复用次数”因为它是衡量能力是否被真正复用的金标准。汇报数字化成果时再留意一个技巧每讲一个模块都要给一个带数字的案例。南航这份PPT里有几组非常清晰的数据报表需求从1个多月压缩到3天业务人员2小时搭仪表板。这些数字比任何技术名词都有说服力。你汇报时也可以把最重要的效率提升、成本节约数字在每个板块第一屏抛出来。双中台的落地顺序也是有讲究的。建议先用一两个月把公共能力盘点清楚再决定先建业务中台还是数据中台。对于大多数企业数据中台往往比业务中台更容易产生第一批成果因为它的见效路径很短建好一个主题域的宽表马上就能支撑一个报表需求。业务中台的改造涉及存量系统迁移周期会更长。顺便说一个我自己的教训。早些时候我帮一家制造企业做数字化规划上来就画中台架构图、梳理微服务清单结果项目推进到一半发现业务部门连需求都不想提信息中心说业务不接受新流程。后来回头看问题出在前置的组织和流程工作没做。从那以后我每次帮企业做中台规划都会先问四个问题谁决策、谁建设、谁提需求、数据最后到谁手里。这四条理不清架构图再漂亮也只是展示品跑不起来的。希望帮到你。本文还有配套的精品资源点击获取