由 superadmin 于 2025/05/12, 17:37 最后修改
              
      Show last authors
| author | version | line-number | content | 
|---|---|---|---|
| 1 | == **一、甲方角色的转变:从被动等待到主动参与** == | ||
| 2 | |||
| 3 | |||
| 4 | **传统甲方画像:只提需求,不管过程** | ||
| 5 | |||
| 6 | 过去在IT服务采购中,我们常常看到一种典型模式:甲方列出一份“功能清单”或者“需求目录”,然后发给各家供应商比价、竞标。整个过程,采购方往往只关注价格和交付周期,而不关心架构适配、服务可持续性、运营体验等关键维度。 | ||
| 7 | |||
| 8 | 这种“把自己当成顾客”的采购心态,本质上是被动的、自限的,甚至会让真正优秀的供应方望而却步。**在数字化时代,甲方早已不是买方,而是服务价值共创的平等一方,甚至是主导方之一。** | ||
| 9 | |||
| 10 | |||
| 11 | **数字化转型背景下的新认知** | ||
| 12 | |||
| 13 | 当组织逐渐向“服务即平台”“业务即软件”的方向演进,采购早已不仅是“买个系统”这么简单。甲方必须在一开始就参与架构选型、工具链搭建、数据安全要求定义、接口标准设计等关键环节中。否则,一旦项目上线,很多限制将无法逆转。 | ||
| 14 | |||
| 15 | ---- | ||
| 16 | |||
| 17 | == **二、为什么甲方要懂云、懂产品、懂投标?** == | ||
| 18 | |||
| 19 | **云计算架构不是技术细节,而是服务逻辑基础** | ||
| 20 | |||
| 21 | “懂云”并不意味着要会配置云主机,而是要理解云服务模型对运维、计费、弹性、安全带来的新要求。以SaaS为例,交付责任、定制能力、升级节奏都与传统软件完全不同。 | ||
| 22 | |||
| 23 | 如果采购者不理解这一逻辑,就容易陷入“买了SaaS,却要求高度定制”的矛盾之中。我们在课上举过某银行引入CRM系统的案例,就是因为甲方团队不了解公有云模型,将传统本地部署的管理思维照搬过去,结果供应商与用户之间长期争执“谁该做什么”。 | ||
| 24 | |||
| 25 | 这个案例我在授课中详细讲解过,最终通过引入双向服务责任矩阵才厘清了边界,也让甲方意识到:**不懂架构,采购就无法设定合理边界。** | ||
| 26 | |||
| 27 | |||
| 28 | **产品认知:不再是“功能全”,而是“价值适配”** | ||
| 29 | |||
| 30 | 现在市面上的IT产品琳琅满目,各种模块组合、交付方式、服务支撑机制层出不穷。甲方如果仅靠“是否具备某功能”“界面是否美观”这些浅层指标做判断,很容易被供应商的演示牵着走。 | ||
| 31 | |||
| 32 | DSV强调从客户旅程出发,把产品价值定义为“是否在用户关键接触点创造良好体验”,而不是“技术参数上的功能叠加”。 | ||
| 33 | |||
| 34 | |||
| 35 | **招投标机制也需要“设计思维”** | ||
| 36 | |||
| 37 | 很多组织在招投标阶段使用的是标准格式的RFP,关注点集中在响应表格、报价模型和履约能力。这种做法虽然看起来规范,但**却极易掩盖真正需要比较的维度**。 | ||
| 38 | |||
| 39 | 比如:是否能快速响应变化?能否适配组织内部已有系统?有没有持续优化机制?这些才是真正影响服务成败的因素。 | ||
| 40 | |||
| 41 | DSV课程提倡将“服务蓝图”和“客户旅程映射”融入到RFP中,让竞标环节更加贴近真实使用场景。 | ||
| 42 | |||
| 43 | |||
| 44 | ---- | ||
| 45 | |||
| 46 | == **三、市场探索的“采购前置化”:先理解再采购** == | ||
| 47 | |||
| 48 | **市场探索是学习过程,不只是供应商考察** | ||
| 49 | |||
| 50 | 很多甲方还认为市场探索就是“参加展会”“听方案演示”“收集资料”。而DSV的视角是,**探索的目的是“理解服务模型”,是一次采购者的自我进化过程**。 | ||
| 51 | |||
| 52 | 真正的市场探索,应该包括: | ||
| 53 | |||
| 54 | * ((( | ||
| 55 | 结构化了解主流服务模式; | ||
| 56 | ))) | ||
| 57 | * ((( | ||
| 58 | 对比不同服务商的架构与承诺; | ||
| 59 | ))) | ||
| 60 | * ((( | ||
| 61 | 问题式访谈了解实施细节; | ||
| 62 | ))) | ||
| 63 | * ((( | ||
| 64 | 用户反馈收集与案例复盘。 | ||
| 65 | ))) | ||
| 66 | |||
| 67 | 如果甲方不在探索期完成这些认知,到了采购阶段就只能“看价格”,最终陷入“低价中标、高价补坑”的恶性循环。 | ||
| 68 | |||
| 69 | |||
| 70 | **让采购成为组织知识的一部分** | ||
| 71 | |||
| 72 | ITIL 4 DSV主张将采购流程嵌入服务管理体系之中,使之成为知识管理、服务改进和流程演化的组成部分。也就是说,**一次采购的过程,不只是项目选择,更是组织知识的积累过程。** | ||
| 73 | |||
| 74 | 例如在大型政务项目中,很多机构已建立“采购知识中心”,记录不同项目中各类服务的选型路径、性能差异、合同执行偏差等,为下一轮项目提供借鉴。这种机制背后体现的,正是采购者能力结构的转变。 | ||
| 75 | |||
| 76 | [[image:1747042557020-106.png||height="322" width="571"]] | ||
| 77 | |||
| 78 | ---- | ||
| 79 | |||
| 80 | == **四、提升甲方采购能力的五个建议** == | ||
| 81 | |||
| 82 | |||
| 83 | **建立基础技术理解路径** | ||
| 84 | |||
| 85 | 采购人员并不需要成为架构师,但必须理解主流技术的结构逻辑。例如: | ||
| 86 | |||
| 87 | * ((( | ||
| 88 | IaaS与SaaS的边界; | ||
| 89 | ))) | ||
| 90 | * ((( | ||
| 91 | 微服务与单体架构的部署差异; | ||
| 92 | ))) | ||
| 93 | * ((( | ||
| 94 | 自动化工具链的基本构成。 | ||
| 95 | ))) | ||
| 96 | |||
| 97 | 可以通过微课程、行业白皮书、服务商培训等方式,逐步构建“非专业但懂判断”的认知能力。 | ||
| 98 | |||
| 99 | |||
| 100 | **熟悉服务旅程与蓝图设计方法** | ||
| 101 | |||
| 102 | 通过ITIL 4 DSV中介绍的“客户旅程七阶段”模型和“服务蓝图”工具,甲方可以更清晰地表达自己的预期与痛点,也更容易理解供应方的交付路径,从而形成“双向理解”。 | ||
| 103 | |||
| 104 | |||
| 105 | **构建交付风险判断力** | ||
| 106 | |||
| 107 | 能够识别出哪些场景需要客户配合,哪些阶段容易反复修改,哪些依赖资源稳定性。这些判断力决定了采购合同是否合理、执行过程是否可控。 | ||
| 108 | |||
| 109 | |||
| 110 | **鼓励跨角色联合采购决策** | ||
| 111 | |||
| 112 | 不仅是IT部门参与,还要联合业务方、法务、数据治理等多个角色,从不同角度对采购事项进行判断。这种机制会让需求更完整、评估更全面、结果更真实。 | ||
| 113 | |||
| 114 | |||
| 115 | **复盘驱动:从每一次采购中学到经验** | ||
| 116 | |||
| 117 | 无论采购是否成功,都应组织复盘会议,记录“需求是否表达清晰”“服务是否满足预期”“哪些环节可以改进”,并沉淀到组织服务采购知识库中。 | ||
| 118 | |||
| 119 | |||
| 120 | |||
| 121 | **ITIL 4大师级课程官方授权讲师长河老师原创,末经许可,不得转载** | 

 ITIL 4官方核心著作
  ITIL 4官方核心著作 
   
   
   
   
  

 复制
 复制 导出
 导出 打印预览
 打印预览 查看源代码
 查看源代码 子项
 子项 内容
 内容 评论
 评论 附件 (1)
 附件 (1) 历史记录
 历史记录 信息
 信息

