PT2-MSS - 2023/10/12 下午

  深信服安全托管服务 MSS 联合运营服务经理 PT2 培训第四天下午。

托管业务风险管理探索分享

  托管业务的项目管理与标准管理的差异是什么？

  项目管理十大领域

1. 整合管理

2. 范围管理 ✔

3. 时间管理 〇

4. 成本管理 ✔

5. 质量管理 〇

6. 项目资源管理

7. 沟通管理 〇

8. 风险管理 ✔

9. 采购管理

10. 项目相关方管理 ✔

11. ✔：需要 PM 进行管理的

12. 〇：托管服务已标准定义的

托管是否适用项目管理？

  托管业务作为 ToB 的服务，服务产品虽然高度的标准化，但由于面向各类客户群体，需求存在多样性及复杂性，托管业务具有经营、项目管理的周期性综合属性；在实践中，我们对标准项目管理进行了大量裁剪以适配业务。

  服务经理需要在执行标准服务的过程中通过自身的能力寻找与客户（个人、组织）实现共赢（业务增/续购、满足预期/真实的安全需求）的路径。

本次内容是风险管理，风险管理能力可能为大家带来什么帮助？

  从运营中心经营的角度来看，有效的风险管理可以提前识别续约的关键障碍，同时拉通相关方投入必要的资源尽力减少风险影响，保障续约的“基本盘”，尤其是一些通过方案融合方式销售的服务，更需要服务经理关注可能存在的风险以保障续约率。

  从项目视角来看，风险管理是维护项目目标达成的重要手段，哪怕没有续约的目标牵引，托管项目的完整交付还是离不开风险管理。

  从个人角度来看，风险管理涉及的识别、分析都是项目管理中的重要能力，且在安全行业中对应理念依然被广泛应用。

风险管理整体思路

1. 风险是什么
   1. 对于项目风险，常见定义为：项目风险是不确定的事情或状况，一旦发生就会对项目目标（如时间、成本、范围等）产生负面的影响。
   2. 风险一般包含三个要素：直接原因、结果、损失
   3. 风险：未发生可能会造成影响
   4. 问题：已发生已造成影响
   5. 问题同时也可能是其他的风险直接原因
   6. 致因可以向下进一步挖掘直到找到根因
2. 风险样例：某项目工作量远超出标准交付工时，严重影响项目成本
   1. 直接原因：售前阶段过多承诺线上额外工作内容
   2. 根本原因：进行对外承诺前，内部缺少工作范围的对齐（内部沟通不畅）
   3. 结果：额外工作量超出标准限制
   4. 损失：项目实际负毛利，影响业务经营
3. 风险管理是在做什么？是把风险可能造成的不良影响收敛至合理水平的管理过程：包括服务经理进行风险识别及分析、制定处置方案、风险处置、跟进监控。
4. 什么是合理水平？
   1. 收益应大于投入，且应尽量最大化，投入应合理（用最小的投入提升客户续约的可能性，并聚焦大资产客户、高潜客户）
   2. 处置后的残余风险应在经营单元内确认是可以被接受的（风险不在定级范围内）。
   3. 服务经理需要做到：从项目维度尽量控制风险收敛至合理水平
5. 风险处置的步骤
   1. 风险识别
   2. 风险分析
   3. 制定处置方案
   4. 风险处置
   5. 风险状态确认
6. 风险管理目前打算怎么做
   1. 服务经理
      1. 线下风险统一录入，强化风险分析能力
      2. 线上录入风险，关注风险处置收益
      3. 工作效率大幅提升
   2. PMO、CSM、质量、平台
      1. 线下风险运营，风险预警提示，风险识别分析赋能
      2. 线上风险运营，风险库持续沉淀
      3. 自动风险生成/预警，自动处置方案匹配

风险识别与分析

  风险识别应该持续贯穿整个项目生命周期

1. 接收、对齐信息的关键环节：项目立项、内外部启动会、月度沟通、汇报等
2. 服务交付的关键环节：交付物提交、应急事件总结等
3. 客户主动反馈的内容：群内回复沟通、私聊内容等
4. 发生问题/事件时：考虑问题带来的风险影响
5. 风险预警时：需要分析是否存在感知度风险

  托管业务中的风险分类

1. 交付类：交付风险、满意度风险
   1. 满意度风险
      1. 感知度 - 组件不全导致的事件少
      2. 感知度 - 内网/专网导致的事件少
      3. 感知度 - 资产少/无服务器资产导致的事件少
      4. 感知度 - 主动闭环/有效预防价值呈现不足
      5. 感知度 - 决策人感知不足
      6. 感知度 - 其他原因
      7. 服务需求 - 不匹配
      8. 服务需求 - 客户要求过高
      9. 服务质量 - 发生重大安全事件
   2. 交付风险
      1. 成本超支风险
      2. 流量不全或存在未解密流量
      3. 其他风险
2. 商务类：商务关系风险、预算风险
3. 风险预警：通过指标识别到可能存在风险的提示，需要人工确认风险是否真实存在

  如何判断是否存在风险 - 感知度风险

MSS 有产品的特性，它的价值是相对固定、明确的，需要找到匹配的客户持续让客户感知到价值，才能持续续费

  满意度风险原因：客户关注的需求没有被满足，分析此类风险就先要能分析客户需求

1. 风险产生的原因
   1. 客户需求与服务价值不匹配
   2. 客户需求与服务价值匹配，服务价值未能有效展现
2. 风险处置投入
   1. 尝试引导客户需求，让客户关注服务价值
   2. 增强客户关注的需求点的价值展现
3. 如何确认项目无风险
   1. 商务类
      1. 客户决策人认可服务价值
      2. 有已通过/预留的预算
      3. 预算流程执行无障碍
   2. 交付类：客户决策人及对接人对服务明确表示满意/符合预期
4. 怎么做风险识别/分析（目标：传递方法）
   1. 阶段一（积跬步）生产流程分析法：了解已知学习风险经验库，了解组织的历史经验教训，遇到已知风险时能识别、在关键环节避免已知风险的发生
      1. 风险列举法指风险管理部分根据本企业的生产流程，列举出各个生产环节的所有风险。
      2. 流程图法指企业风险管理部门将整个企业生产过程一切环节系统化、顺序化、制成流程图，从而便于发现企业面临的风险。
   2. 阶段二（抽丝剥茧）：掌握分析能力，遇到存在风险的表征（问题）时可以上溯分析根因
      1. 鱼骨法 - 找主因
         1. 填写鱼头（按为什么不好的方式描述）
         2. 画出大骨，填写大要因
         3. 画出中骨、小骨、填写中小要因
         4. 用特殊符号标识重要因素
      2. 5Why 法 - 找根因，找到根因后还需反问确认 - 保障逻辑正确
   3. 阶段三（见微知著）：拥有丰富的经验及逻辑推理能力，通过早期的特征提前识别已知/未知风险
5. 风险模型样例 - 价值实现的客观测量
   1. 7×24 监测与响应
      1. 客户消息响应 SLA（工作时间、非工作时间）——企业微信监控
      2. 威胁事件监测通报 SLA（工作时间、非工作时间）——mssp 平台
      3. 威胁/事件准确率——MSSP 平台监测
   2. 有效预防
      1. 威胁处置率（威胁工单、策略工单等）——mssp 平台
      2. 脆弱性处置率（弱口令、漏洞、环境异常、安全盲点等）——mssp 平台
   3. 主动闭环
      1. 事件主动闭环率——mssp 平台（服务经理自主提交）
      2. 事件闭环率——mssp 平台（服务经理自主提交）
      3. 威胁的主动处置率（威胁工单）——mssp 平台
6. 风险定性原则

  风险分析及描述 - 参考

1. 回答问题：客户是否未明确标识过对服务完全满意，需求是否匹配，为什么？
   1. 客户对现有满意度情况（对接人、决策人）；
   2. 需求匹配分析，客户关注点在不在服务价值上，MSS 业务是否能满足其主要安全需求，客户对 MSS 无法满足的安全需求是否理解并有其他解决路径；
   3. 价值感知分析，我们服务的价值点（尤其是客户关注的需求）是否有充分的展现，是否符合客户预期？
2. 找到主因、根因：结合上面的分析结果进行主因、根因的分析
   1. 主因：诸多原因中影响最大的一个或几个原因
   2. 根因：主因背后深层次的决定性原因
3. 分析影响：事件发生了会造成什么影响，影响有多大？示例
   1. 影响成本，XX 人天；
   2. 影响服务交付，服务中止/暂停；
   3. 影响续约；
   4. 影响增购/扩容……

风险与威胁处于不同维度，风险三要素中包含威胁，风险是可能造成的损失，威胁是可能造成危害的来源。

风险处置方案的制定

1. 风险接受：不实施额外风险处置措施
2. 风险回避：放弃行动来避免威胁
3. 风险减轻：采取积极的风险处理措施减少损失发生的可能或降低损失严重程度，需充分考虑风险处置成本

  如何选择应对策略 - 趋近最佳收益（感知度风险）

1. 找对原因：明确主因、根因，确认是需求预期存在差距还是需求匹配存在偏差，我们想达成什么效果，现在的关键障碍是什么？——识别关键障碍（服务经理）
2. 制定方案：我们的方案是否解决了关键障碍（主因、根因），投入后是否能解决问题？——选择正确的投入方向并明确投入举措（服务经理）
3. 决策：根据客户分层及今年可能产出、方案投入成本、实施难度、效果预期、当前人员工作饱和度等数据综合判断是否需要按方案投入，判断方案是否需要调整。（渠道老板）

  投入的目的是提升价值感知、保障客户满意度，将有限的资源优先倾斜向高潜客户，最终达到续费目标。所以对于客户的主动投入需要识别是否“恰当”，那我们我们如何来理解“恰当”呢？

1. 需求方向匹配，客户需求重点是什么，能匹配上我们的哪些增值服务，对于确认不是需求重点的，不做优先投入；
2. 需求满足适度，对于标准交付要求以上的客户，综合投入情况，努力做得比客户预期好一点，但也不用镀金太过——过度投入反而会拖累成本、为后续交付埋下隐患

  对于蔓延需求，如何筛选方案？

1. 需求对客户的重要性/必要性，能解决客户什么问题，是不是应该运营中心承接？——是不是由我们接、我们能不能接
2. 需求多少成本，影响如何？——我们接不接
3. 哪种解决方案最合适？——我们怎么接最好

  感知度 - 服务组件不全，我们需要分析客户情况，制定最适合客户的处置方案

1. 推动组件测试，最终让客户购买对应组件，即转入增购场景，具体参考对应组件增购指引。

2. 控制客户预期，通过现状分析向客户陈述现在缺少哪些组件及有哪些影响（尤其是服务效果）。

3. 分析客户需求，从现有 MSS 价值主张中找到对应的工作或增值服务，按照客户的关注度排序，优先重点呈现标准服务内的工作（比如客户事件少，但是关注资产脆弱性，则可以将标准服务原有事件闭环的工作量投入漏洞管理，重点做好漏洞管理的价值呈现），其次可以依次给客户提供增值服务，直至客户满意度明显提升或超出成本限制、提供完所有增值服务，注意话术中应体现增值服务的“赠送”性质。

4. SIP 属于流量分析设备，可以发现内网流量中的攻击及议程，是最有效的攻击发现方式

5. EDR 属于终端防护设备，可以做到主动查杀、异常行为识别等，弥补在网络流量安全检查上存在的不足

6. AF 属于防护设备，可以做到主动封堵，快速对攻击行为进行处置

  风险状态

1. 待确认处置方案：风险已识别分析，但未确认处置方案
2. 处置中：风险已确认处置方案，但未完成落地举措
3. 已闭环：风险以达到闭环标准，确认已闭环
4. 持续监测：风险暂时无需进行处置/无法处置/已完成处置，但风险仍未达到闭环标准（残余风险可接受）
5. 已转化为问题：风险对应的事件已发生

  持续监测 - 不一定所有风险都可以闭环：虽然可能对一个风险进行了充分的分析，并且执行了当前阶段合理的处置策略，但是风险未得到有效减轻的反馈，此时我们应该持续监测风险。

  处置措施可能无效，风险将被持续监测，直到项目结束且客户及内部均已明确无续费机会。

  风险检视：PMO 定期检视风险，对交付类风险识别、分析、处置的辅导，保障风险描述符合要求，根因分析清晰，对风险处置方案提供辅导意见；

  每周对风险状态进行确认，重点跟进交付 + 商务同时存在风险的项目；

  负责交付类风险的运营工作，包括：风险数据趋势分析，共性风险分析、高处置难度风险分析等。

问题的分析与解决

养成良好的问题处置意识

1. 面对危机有哪些心理状态
   1. 恐慌（可能）：初闻问题，且对自己有重大的直接影响
   2. 担忧（常见）：对问题影响抱有不乐观的预期
   3. 理性（目标）：已经接受问题发生的现状，并着手分析、解决问题
2. 接受问题是有可能发生的，并且现在已经发生了，不用做鸵鸟假装没有发生或者纠结于问题本不应发生（这是后面要做的事情）也不用一味地摒弃情绪，正确地利用情绪推动问题解决
   1. 担忧 - 用于事前准备
   2. 不愉快 - 用于谈判
3. PM 责任制：PM 是项目结果的直接负责人，在项目问题中，PM 需要全周期了解、关注、推动问题的闭环。为什么是 PM 责任制？
   1. 项目体量相对较小，PM 完全有能力及精力跟进整个问题的全周期
   2. PM 应该是最了解客户背景、与客户互动/沟通最多的角色
4. 与干系人进行充分对齐
   1. 自己觉得合适：首先得自己有想法，即：我认为问题该如何解决，设置一个接受变更的心理
   2. 上级觉得合适：拿着预想的方案找上级，获取上级意见，并同步甲方的期望及流程中其他同事意见
   3. 流程节点上的其他人认可：可理解为其他干系人满意，重点是与该问题相关的人去征求他们的意见，并努力让他们达成共识。Tips：可以边征求意见边推进问题解决
   4. 甲方觉得合适：听听甲方的意见，即：甲方关注的问题需要向其征求意见
5. 优先级是动态的 - 动态调整
   1. 新问题加入
   2. 老问题解决
   3. 周边环境变化
6. 积极思考
   1. 充分交换意见：首先要听进去，认真聆听，其次用听引发思考，最后快速把思维点连起来
   2. 快速反馈：真正掌握的快速抓重点，不太熟悉的深入问一下，不了解的明示要思考下
   3. 让人觉得舒服：“温馨提示”好过“例行检查”；“分析利弊”强于“引导推进”
   4. 换位思考：我提出的解决方法对方会怎么想，既定的解决方案大家会怎么执行
   5. 联想：优点：通过联想将知识和实践有机结合；缺点：关联性不一定充分，可能降低效率
7. 不要害怕对与错
   1. 我们会努力坚持正确的，但我们要清楚何为正确的
   2. 虽然有理走遍天下，但是有理不在言高
   3. 保持谦卑的心态，坚持低调的姿态
   4. 小步快跑高效试错，集思广益快速修正
   5. 摆正心态迎发展，修正方向保护航
   6. 不要太过关心他人的语言，要求自己拥有更高的情商
8. 拿不定主意时多沟通
   1. 可引导思考：优秀的 PM/PMO 都是优秀的引导师，不同人的历史经验有助于我们少踩坑，他山之石可以攻玉，他人之言可以解惑
   2. 可增强信息梳理：沟通发起时要带着自己的疑问以及对结果的预期，尽可能地把当前信息介绍全，便于大家帮忙梳理
   3. 可查缺补漏：因视角不同，每个人都一定会有漏项，因经历不同，每个人都可以互相补位

好用的问题解决工作思路

  分析问题

1. 前面的课程中已经给出了常见的风险分析思路，这个与问题分析都是一直通用的，我们在准确地描述出问题的性质以及影响之后进行记录（系统、表格），根据问题的影响大小、紧迫程度、是否由既定方案、干系人等进行下一步的问题分析。

2. 问题分级及处置流程：在质量相关课程中已经明确，通过内外部影响进行问题定级，此处不再重复，本次课程更多的是给出处置的思路与技巧。

3. 问题识别：什么情况算问题？

   1. 客户可能要提出范围变化 → 客户提出了范围变化
   2. 范围变化了，可能要延期 5 个月 → 已经延期，可能需要 5 个月
   3. 交付物 2 次被打回来，满意度可能受影响 → 客户对交付物不满意

4. 问题定性：关于分类和优先级

5. 解决建议：上中下 & 缓中急

   1. 上策：各重要干系人均满意或保留意见不影响大局的应对策略
   2. 中策：一种效果适度的状态，虽然不是很满意，但大家接受起来不痛苦
   3. 下策：找到你和干系人都能接受的最差的结果，但要知道：求其上得其中，求其下得其下，求下必败
   4. 其疾如风：应对紧急突发事件时要确保速度快。如：应急处置先断网（先确保问题不进一步扩大，控制事态）
   5. 循序渐进：中规中矩得应对问题的策略。如：风评后的加固有条不紊
   6. 徐徐图之：现在无法有效推动解决的问题。如：部分硬件加固无法完成，且目前没有足够的推动力（风险较小）

6. 获取支持：巧妙话术解千愁

   1. 友好提问：不论你是谁，真诚谦卑的态度让人深感舒适
   2. 赢得他人喜爱：从喊对名字和称谓开始“我有两个耳朵却只有一张嘴”
   3. 获得认可：尊重从减少争论开始，友善可以拉近人们之间的距离
   4. 接受观点：讨论从赞赏开始，从“先认可对方”出发，杜绝命令、职责、批评和人身攻击，多用第一人称复数
   5. 减少忧虑：项目经理人的座右铭：（我的前半生）不畏将来 · 不念过往
   6. 保持快乐：“我们没有时间报复和对抗”，不要刻意维护自己的形象，关心他人会让自己得到更多的快乐

7. 问题上报：梳理与报告的技巧

   1. 材料准备
      1. 问题背景：历史情况是啥？
      2. 问题描述：咋发生的？
      3. 问题现状：现在咋啦？
      4. 诉求：你想干啥？
      5. Tips：尽可能地全，先有再优
   2. 信息梳理
      1. 信息归类：问题描述里的背景
      2. 优先级：我认为啥是重要的
      3. 靶子：供讨论的部分（引导专用）
      4. Tips：逻辑要清晰
   3. 报告
      1. 结构化：都有哪些模块
      2. 逻辑化：先综述全貌，后分说
      3. 线性化：时间充裕的受讲故事
      4. Tips：千万别一块儿用！

8. 问题关闭：及时关闭完成项

   1. 有效跟踪
      1. 谁跟踪：PM 责任制
      2. 啥时候：随时/按需/其他
      3. 咋跟踪：从看 SDSP 问题模块开始
      4. Tips：千万别跟偏了
   2. 及时录入
      1. 录哪里：SDSP 问题模块
      2. 录点啥：你对问题的建议或方案
      3. 有啥用：备忘！
      4. Tips：注意时效性，咱回头就忘了
   3. 合理关闭
      1. 啥时候：事件不是第一要素
      2. 啥条件：问题处理完了就关
      3. 超时咋办：先看问题是否还存在
      4. Tips：关闭时别把时间放在第一位

紧急问题的解决方法

1. 问题梳理：商讨问题的几个关键指标
   1. 现象
      1. 简要当前发生了什么
      2. 关键影响是什么
      3. 可能存在哪些风险
   2. 思路 & 步骤
      1. 如何遏制当前问题继续发展
      2. “我有一个不健全的想法”
      3. 会引发哪些次生风险
   3. 应急应对策略
      1. 处理次生风险的解决思路
      2. 可能需要谁来支持
      3. 共情：大家一起共担风险
2. 沟通预约：预约时间 & 预发材料，引导提前思考
   1. 牛人上车战术
      1. 预约：先看看对方是否有时间
      2. 预定：跟他上级预定一个时间段
      3. 预上车：拉群，正式明确上车
   2. 粮草先行战术
      1. 预发：给上车的人共情
      2. 预讨论：顺手征集一波意见
   3. 会前引导战术
      1. 识别：明确背靠背意见的差异
      2. 引导：婉转提出一些其他牛人的思路
      3. 注意：只做一轮，不求共识
   4. 充分共情战术
      1. 要点：充分完成一轮意见交换
      2. 效果：可以有效引导客观思考
   5. 时间共享技术
      1. 定时间：同一时间段内共有时间
      2. 定频次：争取一次搞定
3. 会前管理：会议主题与沟通目标确定
   1. 会议主题要明确，沟通目标要简明
   2. 会议流程写清晰，张弛有度不慌张
   3. 讨论方向要明确，跑题偏科需纠正
   4. 快速讨论快决定，紧急推动看反映
4. 时间管理：严控沟通时间和范围
   1. 严控范围：紧急问题处理时重点考虑与问题本身强相关的各项因素
   2. 注重实效：在有限的时间内快速达成共识并快速付诸行动
5. 快速落实：落实节点（会上、会后）
   1. 会前共识落实
      1. 定义：会议开始前已经达成共识的部分
      2. 执行：落实的同时收集并反馈效果供会议讨论
   2. 会中共识落实
      1. 定义：应对当前场景的紧急处理措施
      2. 状态：一边开会一边决议一边实行一边反馈
   3. 会后共识落实
      1. 定义：会中研讨并落实的处理措施及会后决议的待办事项
      2. 状态：跟踪会中落实效果，持续跟进会后决议落实
      3. Tips：当紧前逻辑关系中的节点出现问题时，切莫强行推进后续工作
   4. 后续效果跟踪
      1. 时效：持续，直至问题解决（即：有效关闭）。
      2. 反馈：问题关闭之前持续反馈效果，以便牛人/专家识别风险

如何有效跟踪问题的状态

1. 精准记录：一个好用的问题跟踪模板
   1. 原则 1：工具是为我们提供服务的，不应被工具所束缚
   2. 原则 2：统一的必要跟踪项不可缺少，个性化的跟踪项可根据项目自行设置
   3. 原则 3：接受任何差异化的模板和跟踪思路，但用哪个由 PM 说了算
2. 责任到人：下一步代办由谁完成
   1. 由项目经理负责
   2. 专属的问题 owner
   3. 当前节点的负责人（可能没有）
   4. 下一节点的负责人（这不公平）
   5. 交付团队来完成？
   6. 请上级主管跟进
3. 截止时间：合理控制问题处理截止时间
   1. 快速跟进法
      1. 定义：用最快的速度解决问题
      2. 优点：能够实现快速响应、快速应对、快速解决战斗
      3. 不足：仅能够完成当前问题的处理，难以统筹或顾全大局
   2. 中庸缓冲法
      1. 定义：相对中规中矩的速度
      2. 优点：能够相对更全面的掌握更多信息，考虑更全面
      3. 不足：不适用应急处置，时效性略弱
   3. 循序渐进法
      1. 定义：VUCA 时代的问题解决办法，速度快、见效快、试错成本低
      2. 优点：可以将大问题拆解后分段、分块跟进
      3. 不足：新方法，掌握难度较大，可借鉴的经验不多
4. 效果验证：杜绝挖东墙补西墙
   1. 本项目内拆解一下？观点：我是 PM，我可以拆借一下自己的其他项目，后续补上就好了
   2. 隔壁项目组可支援，观点：我没看见别人在忙什么，他们一定可以支援一下
   3. 请给我弹药，观点：跟上级保持密切联系，相信他们会支持。（会哭的孩子有奶吃）
   4. 找其他区域支撑，观点：试试看，万一别的区域有人可以解决这个问题呢？
   5. 给我来个专家！观点：专家经验丰富，解决问题的能力最强

需求识别与分析

需求识别与分析

  对 MSS 服务而言，开展需求识别是为了更好地了解客户的需求和期望，从而能够更好地开展服务。

  通过需求识别，可以收集和分析用户的反馈和意见，了解他们的需求和痛点，发现潜在的机会和问题，并为产品或服务的改进提供有价值的参考。此外，需求识别还可以帮助企业更好地了解市场和竞争对手的情况，为 MSS 的战略决策涉及提供支持。因此，开展需求识别是服务成功的关键之一。

  需求是被知识储备 - 行业背景了解和知识储备是有效挖掘需求的前提

1. 政策文件：对行业、最新政策文件解读和分析，识别机会
2. 需求树：了解总部下发的需求和其他区域同事开展的需求工作，获得输入、提高效率
3. 行业最佳实践：客户普遍关注同行业其他 MSS 客户的动态和规划，最佳实践可以有效的和客户产生共鸣。
4. 客户的发声：客户的领导、专家会参与一些外部的会议、论坛，还有通过网站、媒体有对外宣传，可以了解到客户的业务动态

如何识别服务需求

  需求识别关键点

1. 意识是核心：接受客户反馈信息后尽量深挖，不仅仅对客户的要求负责，要对要求背后的真实需求负责
2. 关键是识别客户痛点问题及关键时刻：驱动力核心是识别用户的痛点、痛点产生的原因和痛点带来的影响。另外，识别 MSS 用户驱动力的前提是对用户的行业、业务、IT 有一定的了解和积累
3. 招数是辅助，灵活组合话术：话术是方法，不同行业/场景/客户千差万别，打铁还需自身硬，承接 MSS 项目，了解客户的一些信息后，可以从几个方面供验证（仅供参考）
   1. MSS 成功交付的衡量标准是什么？项目交付为客户带来了哪些价值？
   2. MSS 能解决相关客户什么问题？是什么层面的沟通？
   3. 与自己其他 MSS 项目之间存在关联性或共性问题？哪些问题场景是通用的？

  显性需求与隐性需求分析：通常我们都会从显性需求往下走，对要求负责，而没有对隐性需求负责

1. 业务侧带来挑战
2. 挖掘真实需求
3. 简单应答需求
4. 客户所提出服务需求

  需求验证和同步：无论是通过启动会、持续运营、商机洞察得出的需求，还需要进行需求验证和同步的动作，形成闭环。

1. 客户端验证（市场测负责）
   1. 客户内部教练；
   2. 外部行业专家；
   3. 客户不同层级、不同部门；
   4. 主管部门、监管单位；
   5. 咨询机构、设计院、研究所；
2. 需求同步（服务经理）
   1. 向团队成员（业务组长、导师）同步；
   2. 向项目组（销售、售前、技服）同步；
   3. 向配合的渠道同步；
   4. 确保信息的一致性；
3. 渠道端验证（市场侧负责）
   1. 行业集成商；
   2. 行业 ISV；
   3. 枪手；
   4. 确保信息的完整性、准确性；

MSS 服务需求分析

  按照需求类型，MSS 需求可分为通用需求以及行业需求，不同类型客户行业需求类型差异较大。通用性安全需求挖掘旨在提供切合客户实际的安全基础服务，贯穿在 MSS 启动、准备、持续运营各阶段；而行业需求则是建立在不同客户类型群体之上，附带行业属性，更具价值，需贴合客户业务持续深耕。据此，深信服 MSS 为更好提供专属服务，目前设教育、医疗、政府、企业四大行业中心

MSS 需求识别时间点与关键动作

1. 启动/准备阶段
   1. 资产信息梳理
   2. 资产脆弱性问题持续监测和处置
2. 持续运营阶段
   1. 危险监测（恶意攻击）
   2. 威胁通告与处置（如 0day 漏洞，流行病毒）
   3. 安全策略管理
3. 关键时刻/重要时期
   1. 行业关键时刻
   2. 重要时期

托管服务交付质量运作机制

基于价值实现的质量运作机制：如何保障服务价值得以有效呈现并获得客户认可

1. 服务价值的交付状态实时监控
   1. 基于 SOP 的服务过程控制
   2. 基于价值体现的客观度量
   3. 基于客户感知的主观评估
2. 质量问题不贰过
   1. 重要问题即时复盘明确避免二次发生
   2. 共性问题定期复盘明确不贰过跟踪举措
3. 端到端的风险管理机制
   1. 基于价值实现的过程监测和评估做到风险识别的前置
   2. 主观意识识别和客观数据模型的风险判断相关结合
   3. 从识别、分析、处置、跟踪闭环全过程管理确保闭环

  服务价值体验的过程度量与监测：基于 SERVQUAL 模型的服务价值预期差值分析方法

  服务问题管理

1. 问题发现：建立多通道的问题发现和反馈机制
2. 问题分析：专项问题解决小组对问题根因和解决举措进行分析确认
3. 问题处置：解决方案举措的高效落地实施，管理人员提供资源和组织保障
4. 不贰过复盘：重大问题（一/二级）处置完成后立即组织复盘。明确不贰过举措并跟踪落地实施；一般问题定期分析共性及潜在风险，明确不贰过保障机制

  价值实现风险管理

1. 风险识别与发现：从客户交付价值实现的结果体系化的监测服务风险，交付人员阶段性自主识别客户对服务价值的感知和认可风险
2. 风险分析：交付人员和各级管理人员共同参与，逐层升级
3. 风险处置：协同安服、技服、市场、研发各个体系资源调度，共同处置应对服务风险
4. 风险闭环确认：质量和 PMO 部门对风险处置结果进行确认和验证

处理问题和风险时（下一步操作时）同步尽可能多的干系人（他人项目经验丰富，可以提出建设性意见，同时又能大家一起背锅~）

基于价值实现的质量控制规范：

1. 理解客户需求预期
   1. 项目前期对齐客户需求
   2. 清理服务资产信息
   3. 摸清现存安全风险
2. 有效预防
   1. 脆弱性发现与闭环跟踪
   2. 威胁事实监测并处置
   3. 安全基础设施状态检测
3. 7×24 监测与响应
   1. 主动监测与响应
   2. 客户问题 7×24 小时响应
   3. 响应 SLA 和事件准确性可视可控
4. 主动闭环
   1. 安全事件的及时主动处置
   2. 安全问题的持续跟踪
   3. 明确的闭环检视标准
5. 价值呈现
   1. 脆弱性/威胁/事件单触点
   2. 周报/月报/月度沟通总结性触点
   3. 季度/半年度/年度价值汇报

质量状态的测量与评估：

  价值认可的主观评估：基于服务价值实现的客观数据提供客户对服务价值认可情况的客观判断依据，质量部门对在线客户定期调研访谈了解客户关键角色价值的主管感知，主要从如下四个方面考察

1. 整体价值呈现
2. 7×24 小时监测与响应
3. 有效预防
4. 主动闭环

管理办法与技术保障：

  质量管理办法：从安服 BG 组织管理角度定义服务质量的定位和执行纲领

1. 明确质量职责
2. 定义质量问题级别
3. 明确质量奖惩机制

  质量职责描述

1. MSS 交付工程师
   1. 根据项目管理规定和各服务交付规范进行实施，对交付任务的质量负责，如：交付物内容质量、格式规范，交付成果质量等，确保交付任务的成果达到客户预期；
   2. 严格遵守客户现场工作纪律；
   3. 对交付任务中所产生问题的全生命周期负责，确保问题闭环。
2. 渠道安服业务负责人：对服务的总体质量和客户满意度负责，具体体现为
   1. 对齐客户的需求和项目目标；
   2. 对齐客户服务的质量目标，做好各项服务交付任务的质量审核；
   3. 识别项目风险和问题，并推动解决和闭环；
   4. 项目过程中管理客户的预期，做好关键节点汇报，客户满意度存在问题时，推进客户满意度的修复
3. MSS 服务经理
   1. 作为运营阶段对客户服务的第一责任人，按照各项交付标准执行云端服务交付任务，对自己所负责的客户的第一责任人，按照各项交付标准执行云端服务交付任务，对自己所负责的客户的服务交付质量负责，如：交付动作执行规范、交付物输出、关键节点交付效果检视和客户反馈收集等；
   2. 严格遵守安全运营中心服务交付质量红线；
   3. 对自己所负责的客户服务过程中线上交付出现问题的全生命周期负责，确保问题闭环。

  管理办法与技术保障 - 质量问题等级定义

  质量红线要求

1. 客户信息要保密
   1. 禁止将带有客户信息的文件或文本通过公有云盘等互联网环境存放或共享；
   2. 禁止未经客户允许将客户信息发送给项目组成员之外的人员。
2. 服务态度放第一
   1. 禁止在任何情况下与客户发生任何形式的冲突；
   2. 禁止在任何场合以任何形式发表对客户的不当评论；
3. 服务操作须授权
   1. 禁止未经客户明确授权就执行任何变更或扫描操作；
   2. 禁止在服务操作执行前或执行后不告知客户操作详情；
4. 国规行规要遵守
   1. 禁止违反国家网络安全相关法律法规；
   2. 禁止违反客户行业要求的规范和行为准则