前两天 收到一封潜在客户的邮件，这位CIO希望在假期里把所有未来要做的项目梳理一下。当然，其中也包括ITSM的项目。因此，他希望我写一个ITSM项目的大致过程。
我也难得有时间好好的梳理了一下“项目”的过程，因为这不是一个“我提供，你使用”的简单过程。
在项目的过程中，往往充满了“沟通”，充满了“互动（Engagement）”。一个项目的沟通越是充分，项目的质量就会越高。反面是什么情况，提供方本着“客户少操心，我们多费心”的心态不让客户参与。
1.1 创建旅程图（Journey map）首先：创建角色
为了提高每一次互动的质量以及客户的体验，我们需要了解 与谁沟通 ？他们的需求是什么？ 在顾虑什么焦虑什么 ？因此，第一步是定义角色。
图标 | | |
| | 客户方有给钱的，就是投资的。谁决定投资？就是IT治理的人。 |
| | |
| | |
| | |
然后：定义客户阶段
那么这些“互动（Engagement）”都是发生在哪些环节？
从开始考虑购买“产品”或“服务”，在何时，怎样发现了“产品”？如何研究“产品”的效益？将选择怎样的“产品”？最后获得怎样的“体验”？这些会经过一个怎样的过程。
很明显，这个过程不是“提供者”创造价值的过程。而是“客户”的目标之旅。
最后：定义接触点
客户与提供者是怎样接触的？在哪一个阶段，通过什么形式接触？接触的目的是什么，期望要实现什么？双方应该准备什么？
这些准备都是促成每一次“互动”成功的基础。
于是，我得首先把这些 双方接触的点 画出来，并把双方参与互动的角色也体现出来，就是这样一个“旅程图（Journey map）”。
1.2 一个ITSM项目的旅程图（Journey map）前期信息部门通过各种探索和实践，了解了ITIL。
第一步 ，首先是客户方了解多家ITSM厂家的“最佳实践”，也就是和ITSM软件公司进行交流。在这个过程中，肯定是每一个ITSM软件公司都把最好的实践拿出来展示，这也让客户方了解到“最好”的成果是什么样子。
· 通过交流便于客户方了解ITSM行业当前的标准和趋势，进一步明确对ITSM项目的预期和目标。
· 让客户方了解每一个供应商的能力，圈定潜在的供应商。
· 让ITSM软件公司的人了解客户方对ITSM项目的总体目的和方向。
参与人：因为ITSM项目涉及到信息化部门的管理体系以及具体流程，因此在这一步应该是信息部门的管理者，以及骨干人员的参与。
只有信息部门的管理者才能定义ITSM项目的 总体目的 和 方向 。
时长：每一个ITSM软件公司的交流时间一般是1-2个小时。
第二步：调研。调研也就是ITSM软件公司的人来现场与信息部门的每一个组的骨干人员以及一线人员的面对面访谈。通过访谈了解现状，了解现有的管理机制和工作方式，了解每一个组期望改进的瓶颈是什么。
通过调研了解到：
· 信息部门的总体过程；
· 每一个具体工作的现状以及使用的软件工具；
· 每一个具体工作的期望改善的瓶颈；
· 主要的供应商是谁，以及供应商如何提供服务和支持；
调研是解决方案的前提，没有调研就没有针对性的解决方案。
参与人：信息部门的每一个组找一个代表，一般是各组的负责人。例如、运维组负责人，应用系统组负责人，数据组负责人，服务台负责人。
· 关键点： 每一个组都需要 调研，才能全面了解；
· 关键点：只有具体负责人或 一线人员才能把现状中的细节描述清楚 ，而整体信息部门的管理者把握的是总体目的和方向。因此，调研需要找的是具体负责人。
时长：每一个组代表的访谈通常时间为1小时，总体时间通常为1-2天。
第三步：沟通调研报告。ITSM软件公司与信息部门的管理者沟通“调研报告”，这是为了核对调研的准确性。因为，短短1-2天的调研难以完全了解信息部门的现状，而“调研”是出“解决方案”的前提，所以需要与信息部门的管理者核对调研报告。
通过核对调研报告，进一步明确总体目的，以及具体期望的改进机会。
注意，在这一步不止是明确总体目的，还明确了有哪些具体的“改进机会”以及这些改进机会的优先级。这些改进机会对应了解决方案应该有哪些具体“成果”。
参与人：在这一步应该是信息部门的管理者，以及骨干人员的参与。
时长：一般时长为1个小时。
第四步： 建立初期项目组。因为这一阶段属于ITSM的设计阶段，并不是具体的“项目实施”阶段。为了让ITSM的设计具有全面性，也为了在ITSM项目实施阶段得到各方面的协作，为了ITSM在运行阶段的有力执行。
在ITSM的设计阶段的项目组，应该是信息部门各组的主要负责人都能有所参与。包括：应用系统管理，运维管理，数据组，服务台。
第五步：设计管理体系。设计管理体系是“ITIL最佳实践”、“现状”、“经验”三方面的平衡：
国际最佳实践ITIL ：指的是ITIL的原版指引，不是完全照搬ITIL，而是要了解 “解决方案”与ITIL之间 到底有哪些差别，为什么存在这些差别，是不合理还是必要的过渡。
如果“解决方案”几乎与ITIL的边都沾不上。这究竟是参考的管理体系错了，例如应借鉴SAFe体系而不是ITIL管理体系。还是说“解决方案”根本就没借鉴任何管理体系，只是贴了一个ITIL的标签。例如、在解决方案中就没有流程，没有闭环。
现状 ：现状只有信息部门的人最了解，《解决方案》不是一步到位，应该是在ITIL与现状之间平衡。
经验：软件公司的实施经验。
ITSM的设计是软件公司和信息部门的共同设计：
参考国际最佳实践ITIL与现状之间的差别，借鉴ITSM软件公司的经验，选择预期和过渡方案。
参与人：在ITSM的设计阶段的项目组，应该是信息部门各组的主要负责人都能有所参与。包括：应用系统管理，运维管理，数据组，服务台。
时长：一般时长为几个月。因为此时有多家ITSM软件公司或者咨询方给出多个方案，并且方案的设计有时需要反复修订。
第六步：选择解决方案。因为此时有多家ITSM软件公司或者咨询方给出多个方案，客户方需要选择最符合预期，性价比最高的方案。
管理体系的选择 ：有的软件公司会给出贴近ITIL V2的方案，例如、一个中心（服务台）十个流程。也有的会给出“建管融合”的方案，例如、项目管理+工单管理。也会有SAFe的敏捷体系。也有全生命周期和价值流的方案。从范围上也包括省市一体化，集团与公司一体化的方案。同时从技术的部署形式上也包括同一部署或分布式部署的不同方案。
范围的选择：因为信息化管理涉及众多内容，不建议一拥而上的建设所有管理机制，因此需要划定范围。采用整体规划，分段实施的方式。
切入点的选择：需要选择最迫切改善的，价值最大化，确定性最高的内容作为切入点。
实施路径以及过渡方案的选择：解决方案不能过于追求一步到位，先有的管理机制，后有的软件支撑。而很多管理机制的建设需要新的资源，所以需要过渡方案。
第七步 ：梳理详细需求。这是关键的一个环节，需要梳理出ITSM项目能够带来的，具体场景化的“需求”，更正式的叫法应该是“成果（Outcome）”。
“成果（Outcome）”的描述格式是：为了达到什么目的，什么角色需要做什么。
所有的“需求”或者“功能”都是为了实现“成果（Outcome）”。
一次次的“需求”的提出，都是在说是由于 新增 还是修订了“成果（Outcome）”又或者说是是以前设计的“成果（Outcome）” 没有实现 。
ITSM 软件公司根据前期的调研和解决方案，制定具体的一系列“成果（Outcome）”并与信息部门的骨干人员进行逐一核对。
参与人：在这一步应该是信息部门的骨干人员的参与。
时长：一般时长为制定具体的“成果”需要一周，核对“成果（Outcome）”为1个小时，但有可能需要反复修订“成果（Outcome）”。
第八步 ：测试解决方案或考察。“成果（Outcome）”应该都是是摸得着看得见的。因此，为了确保“成果（Outcome）”是可实现的，就需要一个测试过程。
参与人：在这一步建议是与后续ITSM项目和系统相关的技术人员进行测试，也就是ITSM系统的“关键用户（Super User）”。
时长：测试的一般时长为一周。
第九步-第十步-第十一步 ：
在确认了“成果（Outcome）”的实现程度以后，进行招标和采购工作。
第九步：招标；
第十步：协商预期和成本；
第十一步：授权采购；
这些步骤未见得是线性的过程，在这里不赘述了。
第十二步：共同设计具体流程。这一步也叫共同设计，但是和前面的管理体系的共同设计不同的是，这一步是要设计具体的流程了。
我在这一步的经验是，ITSM软件公司应先给出一个“经典流程”作为模板，这个经典流程应该是经过很多其他客户的设计和使用，被反复验证的最佳实践。然后由客户方的管理者或骨干人员对“经典流程”进行讨论和修订。
参与人：根据信息化部门的规模来决定，如果是比较大的信息部门，则具体流程的设计应该与相关科室的负责人一起制定。如果是中型的信息部门，则可以直接与信息部门的管理者一起制定。
时长：共同设计的时长一般为1小时，一方面是避免过度设计，一方面流程的设计是持续优化和修订的过程。
第十三步 ：共同实施。ITSM项目一般会具有一个ITSM的软件系统进行支撑。软件的实施应尽量避免“交钥匙工程”。在很多次的ITSM项目中，是由甲方人员完成的软件配置和实施，或者是软件公司和信息部门共同完成配置，只有这样才能让ITSM系统真正得以落地。
参与人：在这一步建议是与后续ITSM项目和系统相关的技术人员进行测试，也就是ITSM系统的“关键用户（Super User）”。
时长：共同设计的时长一般为三个星期到一个月。
第十四步-第十五步 ：培训。培训是ITIL落地的关键步骤。只有大家都理解并形成共识，才能持久。
· 流程培训；
· ITSM系统使用培训；
参与人：在这一步建议是信息部门的管理者以及全体人员都能参与进来。
时长：培训的时长一般为1-2小时。培训通常不是一次，可能会在不同阶段开展不同的培训，包括体系概念的培训，流程与操作的培训。
第十六步-第十七步-第十八步-第十九步 ：使用。ITIL是否能够真正发挥作用，最终取决于流程得以执行。同时非常重要的是通过数据分析，量化并找到新的改进机会。
咱们也引用一下两句经典语录：
· “流程的生命力在于执行”；
· “数据放进去，是为了拿出来”；
我们经常与很多信息部门一起阶段性的分析数据，通过数据的分析我们发现了哪些流程没有实现闭环，哪些系统存在隐患，业务部门对哪些环节或者系统不满意，也包括ITSM软件有哪些需要改进的地方，需要哪些新的数据分析。
数据分析的形式是会议方式，管理者，技术人员，包括外包公司的人员都有参与，每次会议大致3小时。分析数据的时间间隔大致是一个季度一次。
项目名称 | | | |
| | （1）了解国内和国际运维体系的 标准 和 趋势 ； （2）梳理本组织的运维体系建设的 总体目的 ， 效益 以及现状中可改善 瓶颈的机会 ； （3）发现 潜在供应商 ； （4）识别项目的 风险 ； （5）进一步了解项目的 成本 ； （6）项目 论证 ； | |
设计： 针对本组织的需要和本项目的目的，参照行业标准，设计针对性的解决方案； | （7）建立 项目初期团队 ； （8）辅助潜在供应商进行 详细调研 ； （9）设计和修订 管理体系 ； （10）选择 解决方案 ； （11）梳理 详细需求 ； （12）对解决方案的对应功能进行 测试 或 考察 ； | |
| （13）组织 招标 ； （14）与中标公司协商 预期目标 和 成本 ，并 签订合同 ； | |
| （15）组织项目启动会； （16）客户方收集各类数据，配置各类设备的监测协议； （17）组织供应商 共同设计 管理体系中的具体 流程 ； （18）实施一体化监测系统； （19）组织 培训 ； | |
使用 ：ITSM通过软件落地，通过数据量化工作和系统性能，定期召开数据分析会议； | （20）投产并使用； （21）定期（每个月）召开《数据分析报告》； | |
| （22）了解满意度和差距，以及新的潜在机会； （23）终验和付款； | |
2 ITIL落地的关键点：CMDB无论涉及哪一个价值流，无论从哪一个流程开始入手，CMDB都将是整个ITSM系统的关键点。
CMDB是什么？
CMDB 最基本的是：在CMDB里记录了信息化的所有 “业务系统（Application）” 以及“业务系统”的 “子系统（端系统）” 和子系统中的 “功能（Functional）” 。还有支撑每一个“业务系统”的“IT资源”，包括：数据库实例， 中间件 ，还有服务器、 存储 和网络， IP地址 ， 域名 ，线路等等。
在CMDB中还应该包括：业务部门，干系人，信息部门的所有角色和人员，合同，文档。
也就是说，CMDB把与信息化有关的人、事、物都进行了定义。
CMDB 还应该是：CMDB还应该是关系的定义，所有“业务系统（Application）”与“子系统”和功能的包含关系，以及与数据库实例， 中间件 ，还有服务器、 存储 和网络之间的支撑关系。
也就是说，CMDB将信息系统的支撑体系形成了一个结构化模型。
为什么CMDB是关键？是基础，是地基？
因为，所有的数据都需要有对象。
也就是说，所有的服务请求工单，需求工单，变更单，故障单……等等，这些工作数据都需要有对象。什么对象？就是指的是哪一个“业务系统”，哪一个设备。
· 有了对象，就能调取对象的属性为工单的处理提供信息；
· 有了对象，就能对业务系统，对设备的历史进行沉淀和追溯；
场景 | | |
| 这个软件需求对应的是哪一个 “业务系统（Application）” 的哪一个 “子系统（端系统）” 的什么 “功能（Functional）” ，该功能在设计中的 “业务成果（Outcome）” 是什么？ | 这个软件需求是修订了原来的业务成果？ 还是新增了“业务成果（Outcome）”？ 还是认为某个“业务成果（Outcome）”并没有真正实现？所以提了新需求？ |
| 该故障对应的是哪一个 “业务系统（Application）” 的哪一个 设备 ？或者是哪一个 “网络区域” 中的哪一个 设备 ？ | 该 “业务系统（Application）” 或者 “网络区域” 该是否具有以往出现过的“症状”，什么原因，如何解决。本次故障处理是否发现新的“症状”形成“问题”。 现场排错的时候，物理设备的物理位置在哪里。 |
可以想象一下，如果没有CMDB，虽然流程还可以运行，但我们的所有记录的数据都是离散的。有历史，但无法被整理。有沉淀，但无法被调用。
转播
分享
淘帖
()
