A003【项目管理】一个信息系统项目从立项到运维：各方分工

一、参与方一览

还可能出现两个角色。咨询设计单位受托编制项目建议书、可行性研究报告或初步设计方案；建设单位也可能自行组织编制，是否委托取决于项目要求和自身能力。财政部门负责预算、政府采购管理或财政投资评审等职责，但项目审批、资金安排和评审分属不同程序，不能概括成所有项目都由财政部门直接出钱。

监理和测评机构的工作侧重点不同。监理按合同约定参与项目过程管理与监督；测评机构针对软件功能、性能、网络安全或商用密码应用等特定事项开展检测评估。监理是否常驻、测评机构进场几次，都要看项目规模、合同和工作方案。

图：各方在各阶段的在场情况

二、从需求到立项批复

起点通常是业务部门的一张需求申请单，上面写着“现在的系统不好用”或者“上级要求我们建一个平台”。信息化部门汇总后纳入年度信息化计划，才开始走立项程序。

国家政务信息化项目的审批管理，可参考《国家政务信息化项目建设管理办法》。原则上包括项目建议书、可行性研究报告、初步设计方案等环节；已纳入国家政务信息化建设规划的项目，可以直接编报可研。对于文件规定的特殊情形，可以直接编报可研、初设方案和投资概算。地方政务项目、国企项目及其他信息化项目，还要看本级制度和项目类型，不能直接套用国家项目的全部流程。

项目建议书通常用于说明建设必要性、目标、初步方案、投资匡算和建设周期等，帮助审批方判断是否有必要继续开展前期工作。具体内容和篇幅没有统一的“几十页”要求。

可行性研究报告通常进一步分析需求、建设方案、技术路线、投资估算、预期效益和风险等。所需章节、深度和篇幅由适用规范及审批要求决定，大型项目的报告可能很长。

甲方业务部门：提出业务需求，参加调研，确认业务流程和业务规则，并参与测试、试用和验收。业务部门是否承担项目管理职责，要看组织分工；即使不负责整体管理，也通常需要持续参与需求和业务确认。

甲方信息化部门：牵头编建议书和可研。很多单位没有专职人员，会委托咨询公司代编，甲方负责组织和把关。

甲方财务部门：确认资金来源。政务信息化项目的钱来自财政预算，要先进预算项目库。

咨询设计单位：受托编制建议书和可研。按合同收费，不与后续的承建单位有利益关系，否则要回避。

评审专家：参加可研评审会。技术专家看方案可不可行、架构合不合理；经济专家看投资估算有没有水分。评审意见是批复的依据之一。

审批部门：可能是发展改革部门、行业主管部门或其他有审批权限的单位，具体取决于项目类型和审批权限。批复会约束建设内容、规模和投资等事项；后续确需调整时，应按适用规定履行变更、调整或备案程序，不能简单理解为任何内容都绝对不能改。

乙方：这个阶段还没有正式的乙方。大型项目常见厂商售前提前介入，做技术交流、送方案、陪着调研。这些活动不产生合同关系，费用由厂商自己承担。

监理：还没进场。

这一阶段最常卡住的地方：

• 需求写成“建设一个综合管理平台”，没写清解决什么业务问题，可研编不下去，来回改几轮。
• 项目建议书的投资匡算与可研估算差异较大时，审批或评审方可能要求说明差异原因；是否触发重新报批，要按适用的审批规定判断，不能把 10% 当作全国通用门槛。
• 初设阶段如果调整了已批复的建设目标、主要内容或投资安排，应先判断是否属于允许调整的范围，并按适用规定履行审批、备案或其他程序。

三、初步设计与概算

可研批复之后编初步设计。初步设计通常会进一步细化系统架构、功能、部署、设备配置、安全方案和投资概算等内容；具体章节取决于项目要求。涉及商用密码应用的，还应按适用规定考虑密码应用方案。

对实行概算管理的项目，批复概算会约束项目投资。招标控制价、采购预算和合同金额各有适用规则，不能把概算直接等同于每个采购包的最高限价；如建设内容或投资安排超出批准范围，应按项目适用规定办理调整。

初设也要评审。技术评审重点看架构合理性、云资源测算依据、安全方案完整性、密码应用方案。不少政务信息化项目会要求统筹使用政务云或既有基础设施，并论证云资源需求；是否必须上云、资源如何配置，应以适用政策和项目批复为准。

甲方：组织编制，报批，配合评审答疑。

设计单位：出初设方案和概算。这一份文件的技术深度直接决定后面招标顺不顺。

评审专家：技术评审会，出意见。意见里常出现“功能清单颗粒度不够”“安全方案未覆盖数据分级”“概算中软件开发工作量的测算依据不足”。

审批部门：批复初设和概算。

这一阶段有个两难。功能清单写细了，招标时乙方逐条对标报价，甲方想要的整体效果没人负责；写粗了，评标没有可比性，报价差异巨大没法比。

四、招标

采购方式要先区分项目适用《招标投标法》还是《政府采购法》及其配套规定。政府采购方式包括公开招标、邀请招标、竞争性谈判、单一来源、询价等，符合条件时还可采用竞争性磋商等方式；依法必须招标的项目则按招标投标规则办理。公开招标数额标准、适用条件和例外情形需按预算级次、地区及项目性质判断，不能将这些方式当作一张可任意选择的清单。

公开招标的流程：

1. 编制招标文件，包括技术需求书、评标办法、合同主要条款、投标人资格要求。
2. 发布招标公告。依法必须招标的项目，自招标文件开始发出之日起至投标截止之日止，最短不得少于 20 日；政府采购货物、服务采用招标方式的，也有相应的法定期限。具体还需区分项目适用的法律制度。
3. 发售招标文件，投标人购买。
4. 答疑和澄清。投标人对招标文件有疑问的，在规定时间内提出，甲方书面答复，答复要发给所有投标人。
5. 投标人编制投标文件。技术方案、商务报价、资质证明、项目团队。
6. 开标。当众拆封，宣读报价。
7. 评标。依法组建的评标委员会通常由 5 人以上单数组成，技术、经济等方面专家人数不得少于成员总数的三分之二；特定项目和采购制度可能有不同的具体规定。专家抽取、招标人代表比例及回避要求，应按适用规则执行。
8. 推荐中标候选人，一般 1 到 3 名，标明排序。
9. 依法必须招标项目的中标候选人公示期限，按适用招标投标规定执行；不同采购制度的公告、公示要求并不完全相同。
10. 定标，发中标通知书。

甲方：确定技术需求，编技术需求书，派代表进评标委员会（作为招标人代表，不占专家名额），定标。

招标代理机构：编招标文件，组织开标评标，发布公告和中标公示。甲方自己有能力也可以自行招标。

评标专家：独立打分，推荐候选人。评标委员会成员名单在中标结果确定前保密。

监理：部分项目会在招标阶段委托监理参与需求文件审查或提供咨询意见。监理是否参与招标、能否参与特定评审活动，要结合采购程序、委托范围和回避要求判断，不能视为普遍职责。

乙方：买标书，编投标文件，答疑，投标。投标文件的编制质量直接决定能不能中标，技术方案和报价要匹配。

测评机构：不介入。

这一阶段的风险点：

• 技术需求书写成某厂商产品的参数，形成指向性，被其他投标人质疑甚至投诉。
• 评标办法价格分权重过高，低价中标，后面做不下去，变更和索赔不断。
• 投标人不足 3 家，流标，重新招标，工期整体后推。

五、签约与开工

依法适用《招标投标法》的项目，招标人与中标人通常应自中标通知书发出之日起 30 日内，按照招标文件和中标人的投标文件订立书面合同。履约保证金的比例上限及是否收取，要看适用法律和采购规则；不能将单一规则不加区分地套用到所有信息化项目。

合同内容至少包括：建设内容与范围、工期、合同价款、付款方式与节点、验收标准、违约责任、知识产权归属、保密条款、质保期。

合同签完，两边各自启动内部程序。

乙方：合同评审（法务、财务、交付部门一起看条款风险），内部立项，任命项目经理，组建项目组，划拨预算。

甲方：组建项目组，任命甲方项目经理，明确对接人。甲方项目经理要拿到授权，否则协调不动业务部门。

双方：甲乙双方可能分别开展内部立项、任命项目负责人和内部授权。项目管理方法中常用“项目章程”描述项目授权文件，但企业实际文件名称、签发人和流程不统一；它不能替代双方签订的合同。

监理：签监理合同，组建监理项目部，任命总监理工程师，编制监理规划和监理细则。

开工会：也叫项目启动会。参加人有甲方项目组、乙方项目组、监理。内容是介绍项目背景、明确各方接口人、确认沟通机制和例会安排、确认总体计划。

乙方编制项目实施计划，按合同和项目管理制度提交甲方、监理审查或确认。谁审核、谁批准，以及该计划是否作为正式进度基准，应以合同和项目约定为准。

这一阶段的坑：

• 合同范围跟招标文件、投标承诺不一致。乙方投标时答应的功能没写进合同，后面甲方要，乙方不认。
• 付款条件苛刻，节点付款比例低，乙方垫资严重，影响投入。
• 甲方项目经理没有实际授权，业务部门不配合，需求调研推不动。

六、实施

实施阶段从需求调研开始，到系统具备初验条件结束。典型顺序是需求调研、概要设计、详细设计、开发与集成、内部测试、部署、培训。

甲方业务部门：参加需求调研，确认需求规格说明书，提供测试数据和业务场景，参加用户验收测试。

甲方信息化部门：提供机房、网络、云资源、第三方系统接口，协调内部资源，监督进度。

甲方项目经理：日常对接，组织内部协调会，处理业务部门提出的新需求。

乙方项目经理：编计划、排资源、管进度、管质量、管风险、管沟通。项目周报、月报由他出。

乙方需求人员：调研，写需求规格说明书，跟甲方确认签字。

乙方设计人员：概要设计、详细设计、数据库设计、接口设计。

乙方开发与实施人员：编码、配置、集成、部署。

乙方测试人员：单元测试、集成测试、系统测试，出测试报告。

监理：审乙方提交的各类方案和计划，旁站关键工序（设备上架、系统割接、数据迁移），巡检抽检，主持监理例会，签发监理通知单，审核付款申请并签认支付证书，出监理月报。

测评机构：一般在系统开发完成、准备初验前介入，做第三方软件测评。有的项目在实施中期就进场做过程检查。

专家：一般不在实施阶段介入。出现重大技术方案变更时，甲方可能组织专家论证。

变更控制是这一阶段的主线。任何一方提出变更，都要走变更申请、影响评估、审批、实施、验证。评估要覆盖范围、进度、成本、质量、风险五个方面。监理通常对变更的必要性、技术影响和进度成本影响提出审查意见；最终审批主体和授权范围由合同、项目制度及建设单位内部授权确定。

常见问题：

• 需求蔓延。业务部门边用边提，不写变更单，乙方先做了再说，最后工期和成本失控。
• 甲方环境不到位。机房没准备好、云资源没开通、第三方接口不通，工期延误，责任扯皮。
• 乙方关键人员更换。需求人员和开发人员中途走人，知识没交接，返工。
• 测试不充分。乙方自己测没问题，甲方一用就出问题，根子在需求理解和真实数据差异。

七、初验与试运行

初验也叫初步验收、预验收。有些项目管它叫“用户验收”，这个叫法值得单独说一下。

在常见的软件交付语境中，UAT（用户验收测试）指由用户或业务代表参与的测试活动，用于确认系统是否满足业务使用要求。它通常与项目的初验、终验区分，但实际项目对“用户验收”“初验”等名称的使用并不完全一致，应以合同、测试方案和验收方案对各节点的定义为准。

三个环节的判据不同。UAT 看的是业务场景跑不跑得通，初验看的是合同和需求规格说明书的符合性，终验看的是试运行期的问题有没有闭环、各类测评报告齐不齐。

实际项目可能把用户测试、用户确认和初步验收安排在同一阶段，也可能分开进行。名称本身不能说明完成了哪些工作，关键要核对合同和验收方案中的测试范围、验收条件、缺陷处理要求及签字主体。

项目管理教材中的过程划分与具体项目的交付制度并不完全相同。理解实际项目时，应以合同、测试方案和验收文件为准。

乙方完成开发和内部测试后，提交初验申请，附自测报告、需求规格说明书、设计文档、测试报告、用户手册、部署文档。

监理审核材料，出质量评估报告。甲方组织初验，业务部门派人参加，按合同和需求规格说明书逐项核对功能。

初验通过后是否进入试运行、试运行多长时间，由项目合同和验收方案约定。试运行期间通常会记录运行情况、故障和待整改事项，并安排运维人员熟悉系统；具体期限不宜一概写成 3 到 6 个月。

甲方：组织初验，安排业务部门试用，收集问题，监督整改。

乙方：配合初验，驻场支持，处理试运行期间的问题。

监理：审核初验材料，参加初验，跟踪问题整改闭环。

测评机构：初验前完成软件测评，报告作为初验依据之一。

试运行期常见的分歧：什么算缺陷、什么算新需求。缺陷乙方免费改，新需求要走变更。判断时要对照经确认的需求、合同范围、变更记录和验收标准。某项功能未写入最初的需求规格说明书，不代表任何情况下都自动属于新需求；后续经批准的变更同样可能构成合同范围。

八、竣工验收

终验也叫竣工验收，是项目正式结束的标志。

申请终验要满足这些条件：

• 试运行期满，试运行期间的问题全部整改完毕并经甲方确认。
• 第三方软件测评报告。
• 适用等级保护要求的系统，按规定完成定级、备案、测评及整改等工作，并准备相应材料。具体材料和时间点应结合系统等级、主管要求及项目验收方案确定。
• 依法或按项目要求需要开展商用密码应用安全性评估的系统，准备相应评估报告及整改材料。是否需要密评，应结合系统属性、适用规定和密码应用情况判断。
• 监理总结报告。
• 完整的竣工文档，包括需求、设计、测试、部署、运维、培训各类文档。
• 培训记录和移交清单。
• 合同约定的其他条件。

流程：

1. 乙方提交终验申请和全套材料。
2. 监理审核，出监理总结报告，明确是否同意验收。
3. 甲方组织验收组。验收组一般由甲方代表、监理、外聘专家组成，重大项目邀请主管部门参加。
4. 现场检查、文档审查、功能抽测。
5. 验收组出验收意见，签字。
6. 是否需要向主管部门备案或报批，以及由谁办理，取决于项目管理制度和验收程序。

甲方：组织验收，邀请专家，出验收结论。

乙方：准备材料，现场演示，回答质询。

监理：审核材料，出总结报告，参加验收。

测评机构：报告已经出了，验收时可能被要求解释结论。

专家：验收组里的技术专家，负责判断系统是否达到合同要求。专家签字要担责，所以看得比较细。

审计：有的项目在终验前就介入，做过程跟踪审计。

验收不通过的情况不少见。常见原因是测评报告有未整改的高风险项、文档缺失、试运行问题没闭环。整改完再申请，重新组织验收。

九、结算、决算、审计

三个词经常混用。

结算是甲乙双方算钱。乙方编结算书，内容是合同价加上变更、索赔、签证。甲方或委托造价咨询公司审核，双方确认结算金额。结算完了付尾款，留质保金。

竣工财务决算用于反映项目从筹建到竣工交付的实际财务支出及资产形成等情况。是否需要报财政部门或主管部门审核、批复，以及具体程序，取决于项目资金来源、投资管理制度和单位规定。

审计由依法具有相应职责的审计机关、单位内部审计部门或受托机构按各自权限开展。审计范围可能涉及程序、资金使用、合同履行和工程造价等；是否开展以及何时开展，取决于审计计划和项目安排。

造价咨询公司：编或审工程量清单、招标控制价、结算书。按项目收费。

财政部门：审批竣工财务决算，拨付资金。

审计机关：出审计报告，发现问题要求整改，严重的移送处理。

审计发现的问题集中在：变更没有审批手续、结算量超过实际、设备采购价格明显高于市场、监理签证与实际不符。

十、移交与运维

终验通过后系统移交给运维部门。

移交内容包括：系统管理权限、全部文档、源代码（合同有约定的）、设备清单、账号清单、第三方接口说明、运维手册。

质保期限、免费服务范围、响应时限、质保金或质量保证方式都应以合同为准。项目中可能约定 1 年、2 年或更长的质保期，也可能采用保函等方式替代现金质保金；不能把某个比例视为通用标准。

质保期结束后，系统仍需持续运维。相关服务可能由甲方内部团队承担，也可能委托原承建单位或通过新的采购程序选择服务商；质保期与运维服务期也可能存在重叠。运维内容包括日常巡检、监控告警、备份恢复、故障响应、版本升级、安全加固、数据维护。

甲方运维部门：接管系统，日常运维，提运维需求。

乙方：质保期内免费支持，之后按运维合同服务。

监理：一般不参与运维。运维阶段如果需要第三方监督，会另找运维监理。

测评机构：等级保护测评周期要结合系统等级、适用规定、主管部门要求和风险情况确定。三级系统常见年度测评安排，但不宜把所有等级、所有系统的周期简单概括为统一的“一年或两年”；发现问题后还应按要求整改。

专家：运维阶段基本不介入。系统要重大升级或重构时，会重新走立项程序。

十一、监理这条线

监理通常由建设单位委托，对项目过程实施监督，并按合同和适用规范保持独立、客观。监理与承建单位通常不存在同一项目上的委托合同关系，但监理权限并非仅由这一点产生；能否签发暂停指令、如何生效，应看适用规范、合同约定和授权范围。

监理费不在乙方的中标金额里。它属于甲方项目概算里的“工程建设其他费用”，跟设计费、咨询费、招标代理费并列。项目总投资的构成大致是这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

建设项目总投资
├─ 建设投资
│  ├─ 工程费用
│  │  ├─ 建筑工程费
│  │  ├─ 设备购置费
│  │  └─ 安装工程费
│  ├─ 工程建设其他费用
│  │  ├─ 勘察设计费
│  │  ├─ 监理费
│  │  ├─ 招标代理费
│  │  ├─ 造价咨询费
│  │  └─ 建设管理费
│  └─ 预备费
└─ 建设期利息

监理费用通常列入建设单位的项目费用，并由委托方按合同支付。是否必须单独签订监理合同、采用何种采购方式，要结合项目制度和采购要求判断。付款来源本身不能完全决定监理是否独立，独立性还取决于委托关系、职责边界、利益冲突控制和实际履职情况。

监理服务价格的管理方式需要区分项目性质。国家发展改革委相关文件规定，部分建设项目监理服务实行市场调节价，但政府投资项目及政府委托服务曾有不同的价格管理安排，后续还需核对现行政策。实际费用可按工作量、人员投入、服务范围等协商确定；“合同额的 1% 到 3%”只能视为某些项目中的经验区间，不是统一收费标准。政府投资项目的费用应纳入相应预算或概算管理，调整时按规定办理。

在总承包或代建模式下，合同关系和管理界面会发生变化，但不能据此直接认定监理独立性必然下降。需要查看建设单位、代建单位、总承包单位与监理单位之间的委托关系、合同权限和实际履职安排。

监理进场时间和服务范围由项目要求、合同及适用制度决定。有的项目从招标或设计阶段开始，有的只覆盖实施阶段；不能简单按“政府项目”和“企业项目”一刀切。进场越早，对后面越有利，因为招标文件的技术漏洞监理能提前看出来。

监理项目部一般配三类人：总监理工程师、监理工程师、监理员。大项目按专业分组，每组配一名监理工程师。

监理要出三份文件。投标时提交监理大纲，说明打算怎么监。中标进场后编监理规划，落到具体措施。再往下编监理细则，按专业或按阶段分。

监理的工作内容，行业里归纳成四控三管一协调。

四控：质量控制、进度控制、投资控制、变更控制。

三管：合同管理、信息管理、安全管理。

一协调：组织协调，协调甲方、乙方、以及涉及的其他单位。

实际动作清单：

• 审查乙方提交的实施计划、需求规格说明书、设计方案、测试方案、上线方案。
• 旁站关键工序。设备上架、网络割接、数据迁移、系统上线，监理要在现场。
• 巡检和抽检。看代码管理是否规范、测试记录是否完整、现场是否按方案施工。
• 主持监理例会。周例会或月度例会，出会议纪要，跟踪待办。
• 签发监理通知单。发现问题书面通知乙方整改，严重的签发工程暂停令，整改合格后签发复工令。
• 审核付款申请。按合同节点核对完成情况，签认工程款支付证书。没这个签认，甲方一般不付款。
• 处理变更。评估变更对范围、进度、成本的影响，提出审核意见。
• 组织或参加初验、终验。
• 出监理月报和监理总结报告。

监理的权力边界要说清楚。监理可在合同授权和适用规范范围内提出整改要求、签发相应通知，并对进度款申请等提出审核意见。是否有权签发暂停令、付款审核如何生效，要看项目合同及制度。监理通常不能代替建设单位决定合同范围、投资和重大变更，也不应取代承建单位的内部人员管理。

十二、测评、检测、评估、审计的分工

这些词在项目里频繁出现，做的事完全不同。

软件测试或检测关注合同约定的功能、性能、兼容性等指标；等级保护测评关注信息系统是否符合相应等级的安全要求。两者目标和依据不同，但并非所有项目都必然需要两份报告，是否作为验收材料应以适用规定、合同和验收方案为准。

商用密码应用安全性评估的适用范围，应结合《密码法》及相关配套规定、系统属性、重要程度和具体密码应用情况判断。不能仅凭“用了商用密码”或“达到等保三级”就直接推定所有系统都适用同一要求。

十三、几组容易混的关系

监理和甲方项目经理：甲方项目经理管项目，监理管监督。监理不替代甲方做管理，甲方也不能让监理替自己写方案、做决策。监理如果替甲方干活，独立性就没了。

监理和测评机构：监理主要按约定监督项目过程并跟踪问题；测评机构针对特定指标开展测试或评估。双方工作可能交叉配合，但不能仅按是否常驻来区分。

初验和终验：初验通过进试运行，终验通过进质保。初验是阶段性确认，终验是项目结束。

结算和决算：结算对乙方，算这个合同该付多少钱。决算对项目整体，算这个项目总共花了多少钱。

质保期和运维期：质保期内承建单位按合同承担约定的缺陷修复和支持义务；额外服务是否收费要看合同。运维服务可以另签合同，也可以由内部团队承担，时间安排和收费方式并无统一模式。

甲方项目经理和乙方项目经理：各自对各自的组织负责，不是上下级。甲方项目经理给乙方下指令，走的是合同和监理渠道，不能直接指挥乙方的人。

项目章程和合同：合同是法律文件，约束甲乙双方。章程是内部授权文件，授权项目经理。乙方项目章程的依据是合同，但章程不能替代合同。

十四、两边内部的分工

前面按阶段讲，这一节按组织讲。同一个项目，甲乙双方内部都有好几拨人，搞清楚谁管什么，比记住流程更有用。

甲方内部

甲方项目经理多数出自信息化部门，少数项目由业务部门出人。业务部门出人的好处是业务熟，坏处是不懂技术，容易被乙方牵着走。

甲方内部最常见的问题是业务部门和信息化部门意见不一致。业务部门想要的功能，信息化部门认为技术上不合理或者超出预算，两边僵住，乙方在中间等。这种事没有流程能解决，只能靠分管领导拍板。

乙方内部

销售和项目经理的目标经常不一致。销售希望合同签下来，答应客户的条件越多越好；项目经理希望范围清晰、工期合理。这个矛盾在乙方内部普遍存在，交接环节最容易出问题，售前承诺的东西没写进合同，项目经理接手后才发现。

签字人与对应文件

在项目管理方法中，项目章程通常由发起人或有授权的管理层批准，项目经理负责组织编制或参与编制。现实组织中的文件名称、签批流程和授权人可能不同，应以组织制度为准，不能把某一种教材表述当作所有单位的统一签字规则。

十五、分包和外包：链条变长

前面讲的都是甲方对乙方这一层。实际项目里，乙方下面还有一层甚至两层。

法条依据

《招标投标法》第四十八条：中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件，并不得再次分包。中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。

《政府采购法》第四十八条：经采购人同意，中标、成交供应商可以依法采取分包方式履行合同。分包履行的，中标供应商就采购项目和分包项目向采购人负责，分包供应商就分包项目承担责任。

即以下四条约束：

1. 整体转让不行。把项目整个转给别人，自己只收管理费，这是转包。
2. 肢解转让也不行。把项目切成几块分别转出去，同样是转包。
3. 分包要甲方同意，而且只能分非主体、非关键性的部分。核心功能、主体工程不能分。
4. 接受分包的人不能再分包。链条只能两层。

分包商能否再分包，需按项目适用法律和合同判断。对《招标投标法》所规范的中标项目，接受分包者不得再次分包；建设工程领域还存在转包、违法分包等专门规则。具体项目是否违法，要看工作性质、合同链条、资质要求和实际履行情况，不能仅凭“分包后又找施工队”这一描述作结论。

链条变长以后的关系

1
2
3
4
5
6
7
8
9

甲方（建设单位）
  │  合同
  ▼
乙方（总包 / 中标人）
  ├── 分包合同 ── 软件分包商
  ├── 分包合同 ── 硬件集成商
  ├── 分包合同 ── 弱电施工方
  │                 └── 实际施工的工程队（法律上不允许这一层）
  └── 采购合同 ── 设备厂商

四条关系变化：

合同关系只有一层对甲方。 通常由总包与建设单位签订主合同，再由总包与分包商签订分包合同。分包商的合同请求一般先依据分包合同向总包主张，但是否存在法律规定的例外、建设单位的直接付款义务或其他责任，应结合具体合同和适用法律判断。分包商的工期延误，甲方找总包索赔。

监理只对总包下指令。 监理发现分包的问题，签发监理通知单给总包，由总包去管分包。程序上监理不能直接指挥分包商的人。实际操作中监理经常直接找分包问情况，但书面指令必须走总包。

界面责任要提前划。 多家分包干不同内容，接口在哪、谁负责联调、出问题谁背锅，这些要在分包合同里写死。一个系统上线出故障，网络是 A 家的、软件是 B 家的、服务器是 C 家的，三家互相推，最后是总包兜底。

付款链容易出事。 总包收甲方的钱有账期，付分包也有账期，中间压一段。分包拿不到钱就停工、堵门、找甲方闹。分包合同里常见的“背靠背”条款，意思是总包收到甲方付款后才付分包，这个条款在司法实践中的效力有争议。

总包对分包的管理

• 分包商资格审查。营业执照、资质证书、类似业绩、人员配置。
• 按主合同和适用规定向建设单位或监理提交分包信息、合同或资质材料；是否需要备案、审批或书面同意，以项目适用规则为准。
• 分包人员纳入总包管理。出入证、安全培训、现场纪律，都按总包的规矩来。
• 分包进度并入总包计划。总包报给甲方的进度计划里，要体现分包的节点。
• 分包价款通常由总包按分包合同支付；是否存在建设单位直接支付或其他特别安排，应看法律规定和合同约定。

判断分包安排时要核对什么

需要核对项目适用的法律制度、招标文件、主合同、分包合同、建设单位是否同意、分包内容是否允许，以及分包商的资质和实际履行情况。总包通常仍需按主合同向建设单位承担责任；分包商自身承担何种责任，则要看具体法律规则和合同安排。

十六、设备厂商的位置

设备厂商在项目里通常是供应商，不是承建方。它和乙方的关系是买卖，不是分包。

甲供还是乙供

设备由谁采购，会影响合同关系和责任划分，但不能单凭采购方就判断全部质量责任。还要看设备采购合同、安装集成合同、验收记录和故障原因。

甲供设备容易出现责任界面争议，例如设备故障究竟来自产品质量、运输保管还是安装调试。合同应明确到货验收、保管、安装、联调、故障判定和售后责任。三方共同验收、签字后由乙方保管，只是可能采用的一种安排，不能视为统一规则。

厂商在项目里的四个动作

授权。 部分招标文件会要求原厂授权函或售后服务承诺，但是否可以设置此类条件、条件是否合理，应符合采购规则并与项目需求相适应。代理商的授权等级可能影响厂商支持和价格政策，但不能推断所有项目都必须提供原厂授权。

供货。 按合同型号、配置、数量发货，附原厂证明、保修卡、序列号清单。

实施服务。 设备上架、加电、配置、调试，有时由厂商自己做，有时由厂商认证的服务商做，有时由乙方自己做。这一块经常单独计价，叫“原厂实施服务费”。

维保。 原厂质保期限、项目质保期限和服务范围可能不同，具体看设备厂商政策、采购合同及项目合同。若原厂服务期限短于项目承诺期限，应在采购和投标阶段明确后续服务责任及费用。乙方在投标时承诺“3 年免费维保”，实际是先把厂商的 3 年服务买下来再转售，成本早算进报价了。

厂商报备制度

这是实际项目里影响报价的一个机制。厂商对项目做报备，谁先报备谁拿到特价保护，其他代理商拿不到同样的折扣。所以同一个项目，几家代理商来投标，报价差异可能很大，根子不在集成能力，在于有没有拿到厂商的特价。

甲方在评标时如果只看总价，容易选中一家拿了特价但交付能力一般的代理商。有些招标文件会要求投标人说明与厂商的合作关系，就是为了减少这种情况。

验货环节

如果合同或监理方案要求参与设备到货验收，监理可能开展以下核查：

1. 开箱验货，甲方、乙方、监理三方在场。
2. 核对型号、配置、数量与合同清单，必要时核对序列号。
3. 按合同要求检查合格证明、保修资料和其他随货文件。
4. 对适合现场测试的设备，按验收方案进行通电或功能检查。
5. 签署验货记录，三方签字。

型号替换是常见问题。合同写的是某个型号，到货是配置相近的另一款，代理商说是“升级替代”。监理要按合同清单卡，型号或配置与合同不符时，应按合同约定和验收程序记录、提出异议，并由有权主体决定退换货或办理正式变更，监理不应单方面替代采购人作出所有处置决定。

厂商直接投标的情况

厂商也可以直接作为投标人。这时候它的身份是乙方，不是供应商。原厂投标的优势是价格和政策，劣势是集成能力弱，通常还要找集成商做实施。这种情况下，原厂是总包，集成商变成分包，前面那一节的规则照样适用。

十七、如何理解实际项目的流程

项目管理教材会用启动、规划、执行、监控和收尾等过程组织工作；真实项目还会受到行政审批、预算管理、采购制度、合同约定和单位内部授权的影响。这些流程彼此交叉，未必严格按一条直线推进。

例如，需求调研可能在立项前后反复进行；采购阶段可能要求进一步澄清技术需求；实施阶段发现范围需要调整时，要先评估影响，再按授权审批；初验后是否试运行、是否还要终验，也取决于项目文件。理解某个角色的职责时，可以沿着三条线核对：谁与谁签了合同，谁有权批准这件事，项目文件把责任写给了谁。

项目经理通常无权自行批准超出授权的重大变更；监理不能替代建设单位作出其保留的决策；如果合同约定初验后还要试运行和终验，初验通过就不代表所有交付义务已经完成。

和软考教材的对应

教材的 49 个过程从“制定项目章程”开始。实际的立项和招标在章程之前，教材把它们放在立项管理、项目招投标那部分讲，不属于 49 个过程。

关于软考中项知识点，可续看：

A004【项目管理】软考中项知识点集锦（十大管理领域版）

A005【项目管理】软考中项-项目管理图表速查手册

A006【项目管理】计算题专项：从原理到解题