[b][b][font=微软雅黑][size=3]一、甲方角色的转变：从被动等待到主动参与[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]传统甲方画像：只提需求，不管过程[/size][/font][/b][font=微软雅黑][size=3]过去在IT服务采购中，我们常常看到一种典型模式：甲方列出一份“功能清单”或者“需求目录”，然后发给各家供应商比价、竞标。整个过程，采购方往往只关注价格和交付周期，而不关心架构适配、服务可持续性、运营体验等关键维度。[/size][/font]
[font=微软雅黑][size=3]这种“把自己当成顾客”的采购心态，本质上是被动的、自限的，甚至会让真正优秀的供应方望而却步。[b]在数字化时代，甲方早已不是买方，而是服务价值共创的平等一方，甚至是主导方之一。[/b][/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.数字化转型背景下的新认知[/b][/size][/font]
[font=微软雅黑][size=3]当组织逐渐向“服务即平台”“业务即软件”的方向演进，采购早已不仅是“买个系统”这么简单。甲方必须在一开始就参与架构选型、工具链搭建、数据安全要求定义、接口标准设计等关键环节中。否则，一旦项目上线，很多限制将无法逆转。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][b][font=微软雅黑][size=3]二、为什么甲方要懂云、懂产品、懂投标？[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]云计算架构不是技术细节，而是服务逻辑基础[/size][/font][/b][font=微软雅黑][size=3]“懂云”并不意味着要会配置云主机，而是要理解云服务模型对运维、计费、弹性、安全带来的新要求。以SaaS为例，交付责任、定制能力、升级节奏都与传统软件完全不同。[/size][/font]
[font=微软雅黑][size=3]如果采购者不理解这一逻辑，就容易陷入“买了SaaS，却要求高度定制”的矛盾之中。我们在课上举过某银行引入CRM系统的案例，就是因为甲方团队不了解公有云模型，将传统本地部署的管理思维照搬过去，结果供应商与用户之间长期争执“谁该做什么”。[/size][/font]
[font=微软雅黑][size=3]这个案例我在授课中详细讲解过，最终通过引入双向服务责任矩阵才厘清了边界，也让甲方意识到：[b]不懂架构，采购就无法设定合理边界。[/b][/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.产品认知：不再是“功能全”，而是“价值适配”[/b][/size][/font]
[font=微软雅黑][size=3]现在市面上的IT产品琳琅满目，各种模块组合、交付方式、服务支撑机制层出不穷。甲方如果仅靠“是否具备某功能”“界面是否美观”这些浅层指标做判断，很容易被供应商的演示牵着走。[/size][/font]
[font=微软雅黑][size=3]DSV强调从客户旅程出发，把产品价值定义为“是否在用户关键接触点创造良好体验”，而不是“技术参数上的功能叠加”。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]3.招投标机制也需要“设计思维”[/b][/size][/font]
[font=微软雅黑][size=3]很多组织在招投标阶段使用的是标准格式的RFP，关注点集中在响应表格、报价模型和履约能力。这种做法虽然看起来规范，但[b]却极易掩盖真正需要比较的维度[/b]。[/size][/font]
[font=微软雅黑][size=3]比如：是否能快速响应变化？能否适配组织内部已有系统？有没有持续优化机制？这些才是真正影响服务成败的因素。[/size][/font]
[font=微软雅黑][size=3]DSV课程提倡将“服务蓝图”和“客户旅程映射”融入到RFP中，让竞标环节更加贴近真实使用场景。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[align=center][/align]
[font=微软雅黑][size=3]
[/size][/font]
[b][b][font=微软雅黑][size=3]三、市场探索的“采购前置化”：先理解再采购[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]市场探索是学习过程，不只是供应商考察[/size][/font][/b][font=微软雅黑][size=3]很多甲方还认为市场探索就是“参加展会”“听方案演示”“收集资料”。而DSV的视角是，[b]探索的目的是“理解服务模型”，是一次采购者的自我进化过程[/b]。[/size][/font]
[font=微软雅黑][size=3]真正的市场探索，应该包括：[/size][/font]
[list]
[*][font=微软雅黑][size=3]结构化了解主流服务模式；[/size][/font]
[*][font=微软雅黑][size=3]对比不同服务商的架构与承诺；[/size][/font]
[*][font=微软雅黑][size=3]问题式访谈了解实施细节；[/size][/font]
[*][font=微软雅黑][size=3]用户反馈收集与案例复盘。[/size][/font]
[/list][font=微软雅黑][size=3]如果甲方不在探索期完成这些认知，到了采购阶段就只能“看价格”，最终陷入“低价中标、高价补坑”的恶性循环。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.让采购成为组织知识的一部分[/b][/size][/font]
[font=微软雅黑][size=3]ITIL 4 DSV主张将采购流程嵌入服务管理体系之中，使之成为知识管理、服务改进和流程演化的组成部分。也就是说，[b]一次采购的过程，不只是项目选择，更是组织知识的积累过程。[/b][/size][/font]
[font=微软雅黑][size=3]例如在大型政务项目中，很多机构已建立“采购知识中心”，记录不同项目中各类服务的选型路径、性能差异、合同执行偏差等，为下一轮项目提供借鉴。这种机制背后体现的，正是采购者能力结构的转变。[/size][/font]

[b][b][font=微软雅黑][size=3]
[/size][/font][/b][/b][b][b][font=微软雅黑][size=3]四、提升甲方采购能力的五个建议[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]建立基础技术理解路径[/size][/font][/b][font=微软雅黑][size=3]采购人员并不需要成为架构师，但必须理解主流技术的结构逻辑。例如：[/size][/font]
[list]
[*][font=微软雅黑][size=3]IaaS与SaaS的边界；[/size][/font]
[*][font=微软雅黑][size=3]微服务与单体架构的部署差异；[/size][/font]
[*][font=微软雅黑][size=3]自动化工具链的基本构成。[/size][/font]
[/list][font=微软雅黑][size=3]可以通过微课程、行业白皮书、服务商培训等方式，逐步构建“非专业但懂判断”的认知能力。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.熟悉服务旅程与蓝图设计方法[/b][/size][/font]
[font=微软雅黑][size=3]通过ITIL 4 DSV中介绍的“客户旅程七阶段”模型和“服务蓝图”工具，甲方可以更清晰地表达自己的预期与痛点，也更容易理解供应方的交付路径，从而形成“双向理解”。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]3.构建交付风险判断力[/b][/size][/font]
[font=微软雅黑][size=3]能够识别出哪些场景需要客户配合，哪些阶段容易反复修改，哪些依赖资源稳定性。这些判断力决定了采购合同是否合理、执行过程是否可控。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]4.鼓励跨角色联合采购决策[/b][/size][/font]
[font=微软雅黑][size=3]不仅是IT部门参与，还要联合业务方、法务、数据治理等多个角色，从不同角度对采购事项进行判断。这种机制会让需求更完整、评估更全面、结果更真实。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]5.复盘驱动：从每一次采购中学到经验[/b][/size][/font]
[font=微软雅黑][size=3]无论采购是否成功，都应组织复盘会议，记录“需求是否表达清晰”“服务是否满足预期”“哪些环节可以改进”，并沉淀到组织服务采购知识库中。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]ITIL 4大师级课程官方授权讲师长河老师原创，末经许可，不得转载[/size][/font]




[hr]
原始来源：https://itil.org.cn/thread-365003-1-1.html
迁移说明：本文由旧论坛历史帖子迁移至 ITIL 先锋论坛，用于承接旧链接访问。

[b][b][font=微软雅黑][size=3]一、甲方角色的转变：从被动等待到主动参与[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]传统甲方画像：只提需求，不管过程[/size][/font][/b][font=微软雅黑][size=3]过去在IT服务采购中，我们常常看到一种典型模式：甲方列出一份“功能清单”或者“需求目录”，然后发给各家供应商比价、竞标。整个过程，采购方往往只关注价格和交付周期，而不关心架构适配、服务可持续性、运营体验等关键维度。[/size][/font]
[font=微软雅黑][size=3]这种“把自己当成顾客”的采购心态，本质上是被动的、自限的，甚至会让真正优秀的供应方望而却步。[b]在数字化时代，甲方早已不是买方，而是服务价值共创的平等一方，甚至是主导方之一。[/b][/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.数字化转型背景下的新认知[/b][/size][/font]
[font=微软雅黑][size=3]当组织逐渐向“服务即平台”“业务即软件”的方向演进，采购早已不仅是“买个系统”这么简单。甲方必须在一开始就参与架构选型、工具链搭建、数据安全要求定义、接口标准设计等关键环节中。否则，一旦项目上线，很多限制将无法逆转。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[b][b][font=微软雅黑][size=3]二、为什么甲方要懂云、懂产品、懂投标？[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]云计算架构不是技术细节，而是服务逻辑基础[/size][/font][/b][font=微软雅黑][size=3]“懂云”并不意味着要会配置云主机，而是要理解云服务模型对运维、计费、弹性、安全带来的新要求。以SaaS为例，交付责任、定制能力、升级节奏都与传统软件完全不同。[/size][/font]
[font=微软雅黑][size=3]如果采购者不理解这一逻辑，就容易陷入“买了SaaS，却要求高度定制”的矛盾之中。我们在课上举过某银行引入CRM系统的案例，就是因为甲方团队不了解公有云模型，将传统本地部署的管理思维照搬过去，结果供应商与用户之间长期争执“谁该做什么”。[/size][/font]
[font=微软雅黑][size=3]这个案例我在授课中详细讲解过，最终通过引入双向服务责任矩阵才厘清了边界，也让甲方意识到：[b]不懂架构，采购就无法设定合理边界。[/b][/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.产品认知：不再是“功能全”，而是“价值适配”[/b][/size][/font]
[font=微软雅黑][size=3]现在市面上的IT产品琳琅满目，各种模块组合、交付方式、服务支撑机制层出不穷。甲方如果仅靠“是否具备某功能”“界面是否美观”这些浅层指标做判断，很容易被供应商的演示牵着走。[/size][/font]
[font=微软雅黑][size=3]DSV强调从客户旅程出发，把产品价值定义为“是否在用户关键接触点创造良好体验”，而不是“技术参数上的功能叠加”。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]3.招投标机制也需要“设计思维”[/b][/size][/font]
[font=微软雅黑][size=3]很多组织在招投标阶段使用的是标准格式的RFP，关注点集中在响应表格、报价模型和履约能力。这种做法虽然看起来规范，但[b]却极易掩盖真正需要比较的维度[/b]。[/size][/font]
[font=微软雅黑][size=3]比如：是否能快速响应变化？能否适配组织内部已有系统？有没有持续优化机制？这些才是真正影响服务成败的因素。[/size][/font]
[font=微软雅黑][size=3]DSV课程提倡将“服务蓝图”和“客户旅程映射”融入到RFP中，让竞标环节更加贴近真实使用场景。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[align=center][/align]
[font=微软雅黑][size=3]
[/size][/font]
[b][b][font=微软雅黑][size=3]三、市场探索的“采购前置化”：先理解再采购[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]市场探索是学习过程，不只是供应商考察[/size][/font][/b][font=微软雅黑][size=3]很多甲方还认为市场探索就是“参加展会”“听方案演示”“收集资料”。而DSV的视角是，[b]探索的目的是“理解服务模型”，是一次采购者的自我进化过程[/b]。[/size][/font]
[font=微软雅黑][size=3]真正的市场探索，应该包括：[/size][/font]
[list]
[*][font=微软雅黑][size=3]结构化了解主流服务模式；[/size][/font]
[*][font=微软雅黑][size=3]对比不同服务商的架构与承诺；[/size][/font]
[*][font=微软雅黑][size=3]问题式访谈了解实施细节；[/size][/font]
[*][font=微软雅黑][size=3]用户反馈收集与案例复盘。[/size][/font]
[/list][font=微软雅黑][size=3]如果甲方不在探索期完成这些认知，到了采购阶段就只能“看价格”，最终陷入“低价中标、高价补坑”的恶性循环。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.让采购成为组织知识的一部分[/b][/size][/font]
[font=微软雅黑][size=3]ITIL 4 DSV主张将采购流程嵌入服务管理体系之中，使之成为知识管理、服务改进和流程演化的组成部分。也就是说，[b]一次采购的过程，不只是项目选择，更是组织知识的积累过程。[/b][/size][/font]
[font=微软雅黑][size=3]例如在大型政务项目中，很多机构已建立“采购知识中心”，记录不同项目中各类服务的选型路径、性能差异、合同执行偏差等，为下一轮项目提供借鉴。这种机制背后体现的，正是采购者能力结构的转变。[/size][/font]

[b][b][font=微软雅黑][size=3]
[/size][/font][/b][/b][b][b][font=微软雅黑][size=3]四、提升甲方采购能力的五个建议[/size][/font][/b][/b][b][font=微软雅黑][size=3]
[/size][/font][/b][b][font=微软雅黑][size=3]1.[/size][/font][font=微软雅黑][size=3]建立基础技术理解路径[/size][/font][/b][font=微软雅黑][size=3]采购人员并不需要成为架构师，但必须理解主流技术的结构逻辑。例如：[/size][/font]
[list]
[*][font=微软雅黑][size=3]IaaS与SaaS的边界；[/size][/font]
[*][font=微软雅黑][size=3]微服务与单体架构的部署差异；[/size][/font]
[*][font=微软雅黑][size=3]自动化工具链的基本构成。[/size][/font]
[/list][font=微软雅黑][size=3]可以通过微课程、行业白皮书、服务商培训等方式，逐步构建“非专业但懂判断”的认知能力。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]2.熟悉服务旅程与蓝图设计方法[/b][/size][/font]
[font=微软雅黑][size=3]通过ITIL 4 DSV中介绍的“客户旅程七阶段”模型和“服务蓝图”工具，甲方可以更清晰地表达自己的预期与痛点，也更容易理解供应方的交付路径，从而形成“双向理解”。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]3.构建交付风险判断力[/b][/size][/font]
[font=微软雅黑][size=3]能够识别出哪些场景需要客户配合，哪些阶段容易反复修改，哪些依赖资源稳定性。这些判断力决定了采购合同是否合理、执行过程是否可控。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]4.鼓励跨角色联合采购决策[/b][/size][/font]
[font=微软雅黑][size=3]不仅是IT部门参与，还要联合业务方、法务、数据治理等多个角色，从不同角度对采购事项进行判断。这种机制会让需求更完整、评估更全面、结果更真实。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3][b]5.复盘驱动：从每一次采购中学到经验[/b][/size][/font]
[font=微软雅黑][size=3]无论采购是否成功，都应组织复盘会议，记录“需求是否表达清晰”“服务是否满足预期”“哪些环节可以改进”，并沉淀到组织服务采购知识库中。[/size][/font]
[font=微软雅黑][size=3]
[/size][/font]
[font=微软雅黑][size=3]ITIL 4大师级课程官方授权讲师长河老师原创，末经许可，不得转载[/size][/font]




[hr]
原始来源：https://itil.org.cn/thread-365003-1-1.html
迁移说明：本文由旧论坛历史帖子迁移至 ITIL 先锋论坛，用于承接旧链接访问。