400-8615-123 ITIL4 中的服务策略与设计不是两张孤立表格，而是一条“从业务目标到可交付服务”的连续路径：策略回答“做什么、为什么做”，设计回答“具体怎么做、做成什么样”。两者配合，才能避免IT服务沦为无源之水。
服务策略：先回答“为什么做这件事”
服务策略的核心不是写计划书，而是搞清楚组织为什么要提供某类IT服务、为谁提供、凭什么值得投入。它主要解决三个问题：
- 服务提供：组织选择提供哪些服务来支撑业务目标。这不是罗列服务清单，而是要做取舍——哪些服务必须自建，哪些可以外包，哪些根本不值得做。
- 服务定位：同样的服务，不同业务部门或客户群体的需求可能不同。策略阶段要明确服务的差异化定位，比如财务部门要的是审计合规，销售部门要的是响应速度。
- 业务案例：为每一项服务投入建立商业合理性论证。业务案例回答“这笔钱花下去，业务能获得什么回报”。它也是IT与高层管理沟通的通用语言，没有业务案例，IT服务投入往往难以获得支持。
一个常见误区是：把服务策略等同于年度规划，写一叠PPT就束之高阁。实际上，服务策略的输出应该是清晰的决策依据，比如“哪些服务是核心”“哪些服务允许降级”“新增服务需要满足什么门槛”。
服务设计：把策略变成可交付的蓝图
策略定了方向，设计就要画出可施工的图纸。服务设计关注的是将业务需求转化为具体、可运维、可度量的服务方案。两个关键动作：
- 定义价值流程：不是画流程图，而是找出IT服务在业务流程中真正产生价值的节点。比如订单系统，价值节点可能是“支付成功后的库存扣减”，而不是“接口响应时间”本身。把资源投在价值节点上，才可能产生业务影响。
- 资源管理：人员、技术设施、预算都需要围绕服务目标进行配置。设计阶段就要回答：需要多少人、什么技能、哪些系统、预算如何分配。资源不是越多越好，而是匹配服务级别要求即可。
服务设计的产出物通常包括：服务目录、服务级别协议（SLA）、容量与可用性方案、安全与合规要求、运维流程定义。这些文档不是摆设，而是后续交付和运维的基准。
两者如何衔接：常见问题与回答
问：先有策略还是先有设计？策略做完了，设计是不是照着执行就行？
策略在前，设计在后，但两者不是单向传递。策略阶段定义了“为什么做、做什么”，设计阶段将策略转化为“怎么做、做到什么程度”。实际工作中，设计过程往往需要回溯修正策略——比如发现某项服务设计成本过高，可能需要调整服务定位或业务案例。Servicehot 这类ITSM工具（注：Servicehot 是永服科技旗下的不开源商业产品）在落地ITIL4时，通常会把策略文档与设计产出物关联起来，方便追踪变更。
问：小团队或者单一业务部门，也需要做完整的策略和设计吗？
不需要生搬硬套。ITIL4 本身强调根据组织规模裁剪实践。小团队可以简化：策略部分只需明确“服务给谁用、解决什么问题、预算上限”；设计部分只需定义“服务目录、SLA、责任人”。完整流程适合多业务线、多服务类型的组织，否则会变成文档负担。
实施建议：从最小可行闭环开始
不要试图一次性搭完整个策略和设计体系。建议按以下顺序推进：
- 选一个与业务关联度高的服务，比如核心业务系统。
- 只写一页纸的业务案例，说明服务目标、投入、预期价值。
- 为该服务定义最小的服务目录和SLA，明确“什么算正常、什么算故障”。
- 运行一个季度，收集运维数据和用户反馈，再回头调整策略和设计。
这样做的价值在于：先跑通“策略-设计-运营-改进”的循环，再横向推广到其他服务。比一次性设计完美模板更实际。
补充说明：ITIL4 将服务策略和设计融入“服务价值链”，但核心逻辑仍是“先想清楚再动手”。市面上有开源ITSM工具（如iTop、Zabbix等）可以辅助落地，也有商业产品如 Servicehot 提供开箱即用的流程模板。选择哪种取决于组织的定制需求与技术支持能力。Servicehot 不开源，永服科技提供商业支持；开源工具免费但需自行维护。最终选型建议以实际试用和厂商沟通为准。
