一、一个项目的五个阶段，集成商干的活换了内容

五行里最值得看的是第四行——"上线之后"：

• 过去：项目上线，合同基本就结束了。后面每卖一年维保，卖的是"出问题我来修"。
• 现在：上线只是开始。服务方要持续提供的是"运行状态、成本优化、安全合规"——按月的服务，而不是按年的保障。

这一行变了，前面几行的工作内容也就跟着变了：

• "方案"阶段，从"选一台够用的机器"变成"在几十种服务里选出组合，并且算清成本"。难度上升了——因为过去只要判断一个规格够不够，现在要判断一套组合有没有更便宜的等效方案。
• "准备环境"阶段，从"等货装系统"变成"开账号、配权限、跑迁移"。工作量没少，但性质变了——从体力活变成了配置和脚本活。
• "扩容" 那一行最直白：从"再走一遍采购流程"变成"点几下"。这一格说明的是：项目交付完之后，客户还会有需求，而过去这个需求会变成一个新项目，现在它只是一个操作。

二、一个 100 人月项目，工时花在哪

前三位加起来是 84%。这个分布本身就是结论：

• "迁移与数据搬迁"排第一，说明最费劲的是"把已有的东西挪过去"，不是"造新的"。这也是为什么现实中的上云项目周期经常比预期长——存量系统的复杂度总是被低估。
• "成本优化与治理"排第二，占了将近三成。这件事在老模式里完全不存在——因为老模式里成本在采购那一刻就定死了，之后再没有可优化的空间。而在云上，成本是每个月都在变化的量，所以需要持续有人盯着。 这就是 3-12 要讲的实践。
• "托管运维"排第三，说明"上线"不是终点。24×7 的值守、告警处理、故障响应，这些是持续发生的。
• "培训与移交"只占 6%，但这一项的意义特殊——它说明好的服务方会把能力交给你，而不是留住你。这也是 3-1 里说的"从搬箱子变成卖服务"最实质的区别。

三、名字里的关键词：从"集成"到"运营"

过去叫系统集成商（SIer），核心动作是把零件拼成系统；现在叫托管服务商（MSP），核心动作是让系统一直好用。

这两个名字的差别，落在三件具体的事上：

• 交付物不同：过去交付的是"建好的系统"，现在交付的是"持续可用的服务"。
• 计费方式不同：过去按项目一次性收费，现在按服务按月收费。这意味着服务方和客户的利益方向变了——过去"多做一次改动"就是一笔新收入，现在改动在服务范围里，收入与你用得好不好挂钩。
• 关系长短不同：项目制是一次性的，托管是长期的。所以选择服务方的标准也变了——过去比的是"谁做得快、谁报价低"，现在更该比的是"谁在出问题时响应得住、谁会主动帮你省钱"。

判断你面对的是哪一类，有一个简单的方法：问对方"上线之后，你们还提供什么"。 如果回答是"有问题找我们"，那是老模式；如果回答是"我们每月给你一份用量和成本报告、按季度做一次优化评审"，那是新模式。

四、动手 Demo：工时花在哪三块

# 一个 100 人月的云项目，工时分布
work = {"迁移与数据搬迁": 32.0, "成本优化与治理": 28.0,
        "托管运维（24×7）": 24.0, "安全与合规配置": 10.0, "培训与移交": 6.0}
total = sum(work.values())
head = (work["迁移与数据搬迁"] + work["成本优化与治理"]
        + work["托管运维（24×7）"])
print("项目总工时 %.0f 人月" % total)
print("搬迁＋治理＋托管 = %.0f 人月，占 %.1f%%" % (head, head / total * 100))
print("这三块在老的集成模式里都不存在")

实跑输出：

==================================================================================================
D9 系统关联操作中发生的变化：集成商手里的活换了内容
==================================================================================================
  【一】一个项目的五个阶段

  阶段                过去（卖硬件）              现在（卖服务）
  ------------------------------------------------------------------------------------
  方案                选硬件型号、画机房图        选服务、算成本、设计网络
  准备环境            订货、上架、装系统          开账号、配权限、跑迁移
  上线                驻场部署，连着好几周        迁移＋切换，多为一次性
  上线之后            卖维保，按年签              托管服务（MSP），按月收
  客户要扩容          再走一遍采购流程            点几下

  【二】一个 100 人月项目的工时，花在哪

  环节                          工时            占比
  ------------------------------------------------------------------
  迁移与数据搬迁                32.0 人月       32.0%
  成本优化与治理                28.0 人月       28.0%
  托管运维（24×7）              24.0 人月       24.0%
  安全与合规配置                10.0 人月       10.0%
  培训与移交                    6.0 人月        6.0%
  ------------------------------------------------------------------
  合计                          100.0 人月      100.0%

  【三】名字里的关键词：从【集成】到【运营】
     过去叫系统集成商（SIer），核心动作是把零件拼成系统；
     现在叫托管服务商（MSP），核心动作是让系统一直好用。
     排在前两位的活变成了【搬迁】和【省钱】——
     这两件事在老模式里根本不存在。

读这个输出：第一张表五行里有三行的内容完全换了对象（方案从选硬件变选服务、准备环境从订货变配置、扩容从采购变点鼠标），只有"上线"和"上线之后"这两行还能看出和老模式的对应关系。

第二张表则说明了另一件事：这个项目里最贵的部分不是"建设"，是"搬迁"和"之后"。32 + 28 + 24 = 84 人月花在这三件事上，而它们全都是"让已有的东西在新的地方继续好用"——这说明云项目的本质不是"新建"，是"搬运 + 长期照看"。 理解这一点，就能理解为什么服务方的角色从"建设者"变成了"运营者"。

五、⚠️ 2026 现状

• "托管服务"已经是这个行业的主流形态之一。到 2026 年，围绕云做迁移、优化、托管的服务方数量远超传统的做硬件集成的数量，而且很多是从原来的集成商转型过来的——转型的关键不是换产品目录，是补上运维与成本治理这两块能力。
• 对服务方的评估标准也在变，"会不会省钱"成了重要一项。因为成本优化占项目工时的近三成，而且服务方如果做得好，直接影响客户每月的支出。所以客户开始问的已经不是"你能不能建起来"，而是"建起来之后每月大概花多少、你有什么办法控制"。
• "能力移交"重新变成招标里的硬指标。因为云上的系统客户自己也得会操作（很多东西只有一个控制台、几行配置），所以"做完之后我们自己能不能改"成了必须写进合同的事。这正好对应 Demo 里那 6% 的"培训与移交"——占比不大，但它是判断一次合作质量的试金石。

30 秒实验

找一个你参与过的、请外部公司做过的项目，回想它的结尾：

1. 交付那天，对方给了你什么——一份验收报告、一套账号密码，还是一份"以后怎么自己维护"的文档？
2. 交付之后，你们还有没有联系——是"有问题才找"，还是定期会来一次？

两个问题的答案，基本就分出了老模式和新模式。 如果两个答案都是前者，那说明你们当时拿到的是"一个建好的系统"；如果后者，拿到的是"一个有人负责的服务"。这个差别在项目结束的时候看不出来，但在下一次需求变化时会非常明显。

常见误区

1. 错误：云上不需要集成商了，自己点几下就行。——纠正：点几下能起一台机器，但起不了一套系统。Demo 里给出的工时分布说明：一个 100 人月的项目里，绝大多数时间是花在搬迁、治理、托管、合规这些"点几下解决不了"的事情上。 云降低的是单台资源的门槛，没有降低"从存量系统迁移到一个能长期运转的新环境"的复杂度。这个复合度反而更高了，因为它牵扯的东西更多。

2. 错误：找服务方就是为了省事，能力不用自己会。——纠正：在云上，能力完全外包的风险比自建时代更高。因为自建时代系统是"建于你处、也在你处"——对方走了，机器还在你机房；而云上如果只有对方会操作，你连自己有多少资源、花了多少钱都可能说不清。所以合同里"培训与移交"这一项虽然只占 6% 的工时，却是最不能省的一项。

3. 错误：报价低的服务方更划算。——纠正：这要看报价覆盖了哪些活。按 Demo 的分布，一个云项目的钱主要花在搬迁、优化、托管上。如果某家的报价特别低，通常意味着某一项被省略了——最常见的是"托管运维"和"成本优化"这两项被压缩，结果就是上线之后每个月费用失控，或者出问题时找不到人。比价时要逐项对照"这个价格包含哪些环节"，而不是比总数。

4. 错误：老模式一套流程不能用了，新模式下要全部推倒重来。——纠正：能复用的部分其实很多——需求梳理、方案评审、验收标准、变更管理，这些不因为跑在哪里而改变。真正需要新增的是运行阶段的管理：监控看什么、成本谁负责、权限怎么审。判断标准很清楚：只跟"上线那一刻"有关的部分不用改；跟"上线之后每一天"有关的部分要新增。 第二张表里超过七成的工时，都属于后者。

• ☐ 下一节（3-10 大大简化的系统学习：资格认证）

相关笔记

• 实际业务中发生的变化 —— 上一篇：人怎么干活变了
• 云计算改变了IT行业的世界 —— 本节那条预告的出处
• 云计算也在走向开源化 —— 开源方案下，能力更是自己的事
• 云计算中需要长期支出的费用 —— 那 28% 的"成本优化与治理"具体做什么
• ☁️ 云计算 · 索引 —— 全课路线图