简介：这份资源是中交集团暨中国交建信息化工作管理办法的正式文档，面向企业信息化管理者、制度编制人员及关注大型集团信息化治理的从业者，用于了解大型央企信息化工作的组织架构、职责分工与制度框架。压缩包内仅含1个docx文件，约186KB，内容完整覆盖总则、组织机构与职责、规划与年度计划、预算管理、考核奖惩等章节，并明确了统一规划、统一标准、统一管理、统一投资、统一运营、统筹建设六大原则。文档详细界定了信息化工作领导小组、信息化管理部及中国交通信息中心等主体的职责边界，对各单位信息化机构设置与报备要求也有具体规定。目前已有111人学习，适合需要参考央企信息化制度范本、梳理企业信息化治理体系或编写内部管理办法的读者，可从中获取组织架构设计、职责划分与制度条款表述的完整思路。
1. 从一份 85 条的信息化管理办法，看企业 IT 治理到底怎么落地
很多做企业 IT 的同行拿到一份《信息化工作管理办法》第一反应是"这不就是行政文件吗，跟我写代码有什么关系"。我一开始也这么想，直到有一次帮一家多层级集团梳理系统对接流程，才发现真正卡住项目的从来不是技术选型，而是"谁有权批预算、谁负责定标准、系统上线后谁管数据质量"这些治理层面的问题。这份 85 条的管理办法，本质上就是一套把信息化从"各部门自己搞"变成"全集团一盘棋"的操作手册。它覆盖了组织架构、五年规划、年度预算、项目分类、采购流程、资产台账、标准体系、运维安全、人才梯队、考核激励等完整链条，适合正在做集团级 IT 治理、需要写内部信息化制度、或者要理解大型企业信息化管理逻辑的从业者。下面我按实际落地时会碰到的顺序，把这份办法拆开讲。
2. 组织架构与职责分工：谁拍板、谁干活、谁背锅
2.1 三层组织架构的设计逻辑
这份办法把信息化组织架构拆成三层：领导与决策层、归口管理层、执行与支撑层。对应到条文里，就是信息化工作领导小组（第八条）、信息化管理部（第十条）、各单位信息化管理机构与业务部门（第十二至十四条）。
为什么这么设计？因为大型集团做信息化最怕两件事：一是各子公司各建各的系统，数据打不通；二是业务部门提了需求没人统筹，信息化部门闭门造车。三层架构的核心目的是把"决策权、管理权、执行权"分开——领导小组管审批重大事项，信息化管理部管统筹协调和技术支撑，业务部门管需求提出和推广应用。
这里有个容易被忽略的细节：第八条明确领导小组同时也是信息安全工作领导小组。这意味着安全和信息化在决策层是同一套人马，不是两张皮。实际落地时，这个设计能省掉大量"安全部门说不行、信息化部门说必须上"的扯皮。
2.2 各单位机构设置的硬性门槛
第十二条给了一个明确的时间线：成立三年以上的单位应建立独立的信息化管理机构。这条在实际执行中经常被打折扣，我见过不少单位用"信息岗挂在办公室下面"来应付。但从治理角度，独立机构意味着独立预算权和独立考核权，挂靠模式下信息化主管很难对业务部门提出实质性约束。
第十三条还要求各单位信息化管理机构负责人变化时及时向总部报备。这条看似行政化，实际是保证总部对各单位信息化工作连续性的掌控——换人不断线，规划不推倒重来。
2.3 项目管理的双主体协同机制
第十四条是整份办法里最接近"实操手册"的条款。它规定信息化项目由信息化管理部门与业务部门共同组成项目管理组，分工如下：
| 角色 | 职责范围 | 关键交付物 |
|---|---|---|
| 信息化管理部门 | 立项、技术方案、组织开发、采购实施 | 技术方案、采购文件、验收报告 |
| 业务部门 | 提需求、梳理流程、提供资料、推广、数据质量管理 | 需求说明书、流程文档、推广方案 |
| 信息化主管部门（运维阶段） | 技术支撑、系统运维 | 运维手册、故障处理记录 |
这个分工的核心逻辑是"谁用谁负责数据，谁建谁负责技术"。实际项目中最容易出问题的是推广阶段——系统建好了业务部门不用，或者用了但数据乱填。第十四条把数据质量管理的责任明确划给业务部门，信息化部门只做技术支撑，这个边界划得很清楚。
提示：如果你所在单位正在做信息化制度，建议把第十四条的分工表直接抄进项目管理制度里，比事后扯皮强得多。
3. 规划、预算与项目分类：钱怎么花、项目怎么分
3.1 五年规划与年度计划的衔接机制
第十七条规定每五年编制信息化发展规划，第二十一条要求每年底制定下一年度工作计划。这个"五年规划+年度计划"的双层结构，解决的是"长期方向"和"短期执行"的衔接问题。
规划编制的流程是：各部门/各单位提需求 → 信息化管理部汇总调研分析 → 结合公司战略编制 → 专家委员会评审 → 领导小组审批 → 总裁办公会批准 → 发布。这个流程走下来通常需要三到六个月，所以实际工作中，需求收集必须提前启动。
第二十条还要求建立滚动修订机制。这一点很关键——五年规划不是发布完就锁死，每年可以根据实际情况调整，但修订后要报总部备案。我一般建议客户在每年做年度计划的同时，顺带检查一次规划是否需要修订，把两个动作合并，减少重复沟通。
3.2 预算编制的"两上两下"流程
第二十三到二十六条描述了一个典型的"两上两下"预算流程：
第一上：各单位按通知要求编制预算，经本单位领导小组审批后，次年二月底前上报总部。第一下：信息化管理部初审，重点审查与统建系统冲突或重复的内容，反馈初审意见。第二上：各单位按初审意见调整预算，总部各部门第四季度提下一年度需求。第二下：信息化管理部编制整体年度预算，报领导小组审批后反馈各单位执行。
这个流程里最值得注意的是第二十四条的审查重点——"不符合顶层设计以及与统建系统冲突或重复的预算内容"。翻译成大白话就是：总部已经建了统一系统，你再单独建一个功能重叠的，预算不给批。这条是防止重复建设的关键闸门。
第二十七条还要求各单位信息化预算单独列支、专款专用。实际执行中，这条能有效防止信息化预算被挪用到其他领域。
3.3 一类项目和二类项目的分类管理
第三十条把信息化项目分成两类：
- 一类项目（统建项目）：总部统一组织标准编制、系统设计研发和建设推广。
- 二类项目（自建项目）：各单位在顶层设计框架下，遵循"主干统一、末端灵活"原则自行建设。
这个分类是整个管理办法的核心创新点。它的逻辑是：涉及全集团共性的系统（比如财务、人力、主数据）由总部统建，避免各建各的；各单位个性化的业务系统可以自建，但必须与统建主干对接。
第三十二条特别强调，一类项目各单位"不得开展与统建主干重复的建设工作"。第三十三条进一步要求各单位充分利用集团数据中心资源，原则上不再新建数据中心。这两条合在一起，就是在技术上封死了"重复建设"的口子。
实际操作中，判断一个项目是一类还是二类，我一般用三个问题来筛：这个系统是不是多个单位都要用？数据是不是需要集团层面汇总？是不是涉及集团统一标准？三个都是"是"，就是一类；都是"否"，就是二类；介于中间的，需要信息化管理部来裁定。
4. 采购、资产与标准：三个最容易踩坑的环节
4.1 采购方式的适用条件
第三十九条规定信息化采购原则上采用招标方式，第四十条给出了三种例外：竞争性谈判、询价采购、单一来源采购。这三种方式的适用条件是"延续性的软件开发项目"和"不宜采用招标方式的项目"。
实际工作中，最容易出问题的是"延续性开发项目"的界定。我见过有的单位把一个全新项目拆成"一期已建、二期延续"来规避招标，这在审计时是高风险项。合理的做法是：如果二期与一期在技术架构、开发团队、业务逻辑上高度连续，且金额在合理范围内，可以走竞争性谈判；如果是独立的新增功能模块，建议重新招标。
第四十一条要求对服务商进行综合考评、择优选择。这个考评不能只看价格，还要看技术能力、行业经验、售后服务。我一般建议客户建立一个简单的评分表，技术方案占40%、项目经验占30%、报价占20%、售后占10%，比单纯比价靠谱得多。
4.2 信息化资产的分类与管理要求
第四十三条把信息化资产分成四类：硬件资产、软件资产、数据资产、无形资产。每类的管理要求不同：
| 资产类型 | 定义要点 | 管理重点 |
|---|---|---|
| 硬件资产 | 单价≥3000元的信息类物理设备 | 购置、验收、登记、入库、保管、运维、盘点、报废 |
| 软件资产 | 购置的软件产品和定制开发的软件系统 | 登记、许可管理、补丁升级登记备案、定期盘点 |
| 数据资产 | 系统运营过程中产生的信息数据 | 存储、使用登记、安全防护、统计盘点 |
| 无形资产 | 软件著作权、专利权、商标权等 | 知识产权申报和登记 |
硬件资产3000元的门槛线值得注意——低于这个单价的设备不走固定资产流程，但也要有台账管理。软件资产的"许可管理"是合规重点，尤其是商业软件，许可证数量不够是常见的审计问题。数据资产的管理在第四十六条里提到"在集团统一的数据资源规划下进行管理和应用开发"，这意味着数据资产不是各单位想怎么用就怎么用，要服从集团统一规划。
4.3 标准体系的编制与执行规则
第五十条把信息化标准分成五类：基础设施标准、技术支撑标准、业务应用标准、安全保障标准、管理服务标准。标准的编制由信息化管理部组织，总部业务部门和各单位联合编制。
第五十二条和第五十三条是执行层面的关键条款：
- 标准发布后，拟建系统直接应用新标准，已建系统对照转换、逐步过渡。
- 标准体系未包含的内容，各单位可自行制定，但需报总部备案。
- 自行制定标准与公司标准冲突时，执行公司标准。
这三条合在一起，形成了一个"统一标准为主、自行制定为辅、冲突时以上级为准"的标准管理框架。实际落地时，最常见的坑是"已建系统对照转换"这一步——老系统改造标准往往比新建系统更费钱费力。我的经验是，在规划阶段就列出需要改造的老系统清单，按业务重要性和改造成本排优先级，分批次推进，不要试图一次性全部改完。
5. 运维、安全与人才：系统上线后才是真正的考验
5.1 运行管理与运维管理的边界
第五十五条到六十一条讲的是"运行管理"，第六十二条到六十七条讲的是"运行维护及安全管理"。这两个概念容易混淆，实际边界是：
- 运行管理：侧重系统上线后的应用推进、用户培训、权限管理、数据质量管理、需求变更管理。责任主体是业务主管部门和信息化主管部门共同组成的管理机构。
- 运行维护及安全管理：侧重网络、服务器、应用、数据库、存储、安全防护、机房等基础设施的技术维护。责任主体是信息化主管部门。
第五十八条的权限管理原则值得单独拎出来："谁授权谁负责、谁批准谁负责"，账号密码设置必须符合安全管理体系规定，定期组织用户岗位与权限的符合性检查。这条在实际执行中最容易被忽视——很多单位的系统权限一旦分配就没人复查，离职人员的账号还留着，这是安全审计的高危项。
5.2 安全管理的角色配置
第六十五条要求设置五类管理角色：网络管理员、系统管理员、数据库管理员、安全管理员、安全审计员。这五类角色的核心设计原则是"三权分立"——系统管理员管配置，安全管理员管策略，安全审计员管监督，三者相互制约。
实际落地时，小单位往往一人身兼多职，这时候至少要做到"安全审计员不能由系统管理员兼任"。第六十四条列出的安全管理范围包括物理安全、网络安全、主机安全、应用安全、数据安全、备份恢复、安全管理制度，基本覆盖了等保2.0的主要维度。
5.3 人才队伍的配置与培养
第六十八条要求配备四类信息化管理人员：需求管理人员、技术管理人员、安全管理人员、运维管理人员。人员数量应与单位规模相适应。
第六十九条到七十三条讲的是人才培养和队伍建设，核心要点包括：建立人才梯队、重视职称评审和培训考证、引进高水平人才、建立人才交流机制、组织各类培训。第七十一条特别提到"逐步建立自主的信息化建设队伍"，这意味着不能长期依赖外部服务商，要有自己的技术力量。
第七十条要求业务部门设立信息化专职或兼职人员，负责本部门的信息需求收集和系统推进。这个设计很务实——信息化部门不可能懂所有业务，业务部门里必须有人对接。
6. 避坑与排查：制度落地时最容易翻车的五个地方
6.1 规划编制完了就锁进柜子
现象：五年规划发布后没人看，年度计划跟规划脱节，规划成了一纸空文。原因：规划编制时没有建立与年度计划的映射关系，也没有指定滚动修订的触发条件。解决：在规划里明确每年需要回顾的指标项，把年度计划的编制流程与规划修订流程合并，每年底做计划时顺带检查规划是否需要调整。
6.2 预算初审变成"一刀切"
现象：各单位报上来的预算被大量砍掉，导致真正需要建设的项目没钱做。原因：初审时只盯着"与统建系统冲突"这一条，没有区分"重复建设"和"个性化补充"。解决：初审时按第二十四条的要求，重点审查冲突和重复，但"原则上不干预各单位自建项目预算"。建议建立一个简单的判定表：功能是否与统建系统重叠、数据是否需要集团汇总、是否涉及统一标准，三个都"是"才砍。
6.3 一类项目推广时业务部门不配合
现象：总部统建的系统推下去，各单位业务部门不用，或者用了但数据乱填。原因：第十四条虽然规定了业务部门负责推广和数据质量，但实际执行中缺乏考核抓手。解决：把系统推广和数据质量纳入第七十九条的信息化考核体系，与各单位主要负责人的绩效考核挂钩。同时，在项目立项阶段就让业务部门深度参与需求梳理，增强"自己的系统"的认同感。
6.4 标准冲突时不知道执行哪个
现象：各单位自行制定的标准与公司标准冲突，项目组不知道该听谁的。原因：第五十三条虽然规定了"执行公司标准"，但实际执行中缺乏标准冲突的识别和裁决机制。解决：在标准发布时附一份"标准对照表"，列出公司标准已覆盖的领域；各单位自行制定标准前，先做一次对照检查，有冲突的提前报信息化管理部裁定。
6.5 运维和安全角色一人兼任
现象：小单位人手不够，网络管理员、系统管理员、安全管理员由同一人担任。原因：第六十五条的角色配置要求与实际人员编制之间存在差距。解决：至少保证安全审计员独立于系统管理员。如果实在无法满足，可以通过总部统筹或区域共享的方式解决，比如几个邻近单位共用一名安全审计员。
7. 从制度到落地：一份可操作的检查清单
制度文件最大的问题是"看起来什么都说了，做起来不知道从哪下手"。我的习惯是把管理办法拆成一张按时间轴排列的检查清单，每个节点对应具体条文和交付物。下面这张表是我在实际项目中反复用过的版本，你可以直接改成自己单位的格式。
| 时间节点 | 动作 | 对应条文 | 交付物 |
|---|---|---|---|
| 每年10月 | 下发预算编制要求 | 第二十三条 | 预算编制通知 |
| 每年11-12月 | 各部门/单位提需求、编预算 | 第十七、二十五条 | 需求清单、预算草案 |
| 次年2月底前 | 各单位上报预算 | 第二十三条 | 预算上报表 |
| 次年3月 | 信息化管理部初审预算 | 第二十四条 | 初审意见 |
| 次年3-4月 | 各单位调整预算 | 第二十四条 | 调整后预算 |
| 每年底 | 编制下一年度工作计划 | 第二十一条 | 年度工作计划 |
| 每年底 | 总结全年工作 | 第二十二条 | 工作总结 |
| 每五年 | 编制信息化发展规划 | 第十七条 | 规划文本 |
| 规划编制年 | 专家评审、领导小组审批 | 第十八条 | 评审意见、审批文件 |
| 项目立项时 | 判定一类/二类 | 第三十条 | 项目分类认定 |
| 项目验收后 | 后评估 | 第三十一条 | 后评估报告 |
| 每年度 | 信息化考核 | 第七十九条 | 考核结果 |
| 每年度 | 资产盘点 | 第四十四、四十五条 | 资产台账 |
这张表的关键在于把散落在各章的条文按时间轴串起来，让执行的人知道"什么时候该做什么"。我一般会在年初把这张表发给各单位的对接人，每完成一项打个勾，年底考核时直接看这张表的完成率。
还有一个实操技巧：把第七十九条的考核与这张检查清单挂钩。考核不只看结果，也看过程——预算有没有按时报、规划有没有按时修订、资产有没有按时盘点，这些过程指标比年底看几个数字更能反映信息化管理的真实水平。
从那以后我每次拿到类似的制度文件，都会先做一张这样的时间轴检查表，再开始逐条对照落地。制度是死的，执行是活的，把条文翻译成动作和时间节点，才算真正读懂了这份管理办法。希望帮到你。
本文还有配套的精品资源，点击获取
