说说ITSM项目实战那些事儿（二）

二.实操环节

嘿，经过一番脑力激荡的咨询阶段，咱们终于要卷起袖子，一头扎进ITSM项目的实战环节了。这可是动真格的时候，每一步都得踩实了，咱们才能顺利登顶！

1.实施准备：准备到位，事半功倍
老话说得好，兵马未动粮草先行。实施前的准备工作就是咱们的“粮草”，得精心筹备。你得请那些身经百战的实施顾问到场，让他们亲自上阵，来一场实打实的热身。别以为随便派个人应付一下就行，那可是给自己挖坑呢，最终要么重头再来，要么直接凉凉。所以，不管对方多大的来头，咱们都得敬畏专业，认真对待！

• 服务资源梳理：根基要打牢

服务资源	业务描述	技术确认
组织	尽可能涵盖在系统中出现的组织组织定位分用户(客户)方，服务方，供应商	系统内置还是LDAP或其他

清晰划分服务方、用户方和供应商的角色，确保每一环都有对应的责任主体。使用系统内置或LDAP等工具，将这些组织信息妥善管理起来。

服务资源	业务描述	技术确认
人员	尽可能涵盖在系统中出现的联系人，用户类型：普通用户、工程师、管理人员、系统管理员	系统内置还是LDAP或其他

从普通用户到系统管理员，每个角色都需明确定义，这不仅是为了管理上的便利，更是为了确保每个人都能在其岗位上发挥最大效能。

服务资源	业务描述	技术确认
团队	逻辑组合	合理的团队分工促进工作效率

构建虚拟团队，根据服务需求灵活组合，比如工程师团队，确保每个服务都有专业的支持。避免“大锅饭”式的低效，明确分工，提高效率。

服务资源	业务描述	技术确认
区域（可选）	存在多级区域客户需要明确	有助于区域用户请求按就近原则分发到就近的服务团队或工程师(可选)
办公点（可选）	存在相距较远的多个办公地址的场景需要	为更细致的分发策略提供基础数据支持

对于多点布局的企业，明确区域信息至关重要，可以实现快速响应，减少不必要的时间浪费。

服务资源	业务描述	技术确认
节假日	一般提前设定国家法定节假日	强烈建议设置，为值班安排及SLA统计提供基础数据

预先设定好节假日，这不仅关系到SLA的计算，也是合理安排运维值班的必要前提。

上面列举的是几个主要服务资源描述，其他服务资源请大家根据实际项目裁定。

• 配置资源管理：现代版升级
  CMDB（配置管理数据库）得跟上时代，不光是硬件软件，空间资源、产品文档，一个都不能少，统统要管起来。

配置资源	业务需求	技术需求
空间资源	数据中心->机房-机柜	树形视图

从数据中心到机柜，每一层的详细信息如同一张精确的神经系统图谱，让设备定位和管理变得轻而易举。

配置资源	业务需求	技术需求
CMDB	硬件设备+软件应用资源	支持导入

它不仅是设备的记录簿，更是资产与技术管理的桥梁，要足够灵活强大，支持导入导出，与业务系统紧密集成。

配置资源	业务需求	技术需求
业务系统	以业务系统为单元关联各配置资源	形成业务系统拓扑

确保每个业务系统都有对应的运维团队和业务负责人，这样IT与业务部门之间才能有效沟通，形成合力。

配置资源	业务需求	技术需求
产品	记录所涉产品为后续序列号及备品备件管理提供信息	支持导入
文档	作为内部资料的载体提供,方便配置和工单的关联	支持上传下载

每一个产品、每一份文档都是宝贵的资源，妥善管理它们，不仅为日常维护提供了便利，也为未来可能出现的任何情况预留了“说明书”。

2.服务设计：细节决定成败
服务设计，就是咱们的蓝图，得用心勾勒每一笔。这不仅仅是画个大概，得细化到每个螺丝钉

• 服务包
  分门别类，就像超市里的商品架，员工服务、基础设施服务、网络系统、软件应用，一目了然，管理起来也方便，数据分析更是信手拈来。
  举个例子：

一个集团信息中心的服务包设计	一家IT服务商的服务包设计
-员工IT服务 - 基础设施服务 - 网络与系统 - 软件与应用服务	- 标准服务 - 增值服务 - 战略大客户服务

• SLA设计
  SLA得具体到每项服务，不能一刀切，但也不能无限拖。哪怕设定个宽松点的，比如480分钟响应，240小时解决，也好过没个准信儿。随着IT环境变化，SLA也得跟着调整，不能僵化。

未完待续...