收之东隅、收之桑榆～EPSON中国的BSM
【插图说明】爱普生BSM之“行政服务管理系统”上线会议现场。
【导言、EPSON中国的BSM、总务服务管理系统】业务服务的有效管理(Effective BSM)、其实也就保障了业务的安全(Business Security)。这和“IT服务管理(ITSM)在流程化方面根本保障了信息化的安全”是同样的道理。国津的咨询师们又一次遇到这样的案例：去年冬天，爱普生中国的总务部门和IT部门都决定要实施国津的BSM系统，之后我们配合相关用户、项目组相继开始了项目实施工作，正所谓“收之东隅，收之桑榆”（这个是古成语稍加修改的，也挺好用）。ITSM只是BSM的一部分，而BSM的客观需求在本案例里面又一次体现了出来。国津新闻里面前不久另外有一篇专门介绍BSM应用于汽车行业质量控制系统案例的文章，读者朋友们可以一并参考。关于BSM的具体概念说明，也请参考本文后面的附录、【BSM业务服务管理体系，一只无形的手】。
1.客户痛点
爱普生中国的业务发展和信息化建设的进一步成熟带来了行政管理上的问题，公司众多员工每天申报行政请求都上百条，所以公司急需一套ITIL系统来规范管理行政部门的事务。
行政总务部门存在的问题:
(1)行政目录众多，没有统一的问题处理方式。
(2)依赖行政管理人员的经验，对于用户的请求，主要以电话，邮件，纸质申请为主，对于全程的操控不容易掌握。
(3)用户体验行政服务的时候，沟通方式欠缺，用户满意度低，经常出现投诉等现象。
(4)对于行政处理人员，依然依赖于经验式的评审方式，没有具体的考核依据。
2.项目简要历程
3.项目实施内容
【注】本文的项目截图，仅仅是该项目测试环境的部分节选示意截图，供读者朋友们参考。
（1） 行政系统流程
（2）总务系统服务目录及SLA
4.项目部署后达到的效果
（1）强化了IT部门和行政部门人员角色权限和责任分工，更好的划分了人员的职责，避免因为职责不清造成无法解决的请求。
（2）建立了行政部门的服务台，由服务台人员统一分配请求，并对事件进行追踪和处理
（3）建立了总务部门针对服务目录的SLA，并且通过邮件可以对即将超时的请求进行提醒，提升了请求的解决率，也为年底考核提供依据。
（4）加强了与用户的沟通，请求结束后会自动发送邮件到用户邮箱，通过定制化的用户调查，可以填写用户意见并对服务进行评价，大大提升了客户的满意度。
（5）形成了总务部门的知识库，通过知识库服务台人员和用户都可以自助解决问题。
节选的系统实施后效果截图：
【结语】正如本文开始所说BSM/ITIL理念适合各行各业、助力政府、教育行业、金融行业、制造业、快递业、传统企业和各种新兴产业，例如爱普生这种传统电子制造企业，并且由行政总务部门牵头使用，反映出了无法回避的时代的洪流：科技提升企业竞争力，同时科技服务企业的机制也需要提升、科技带来的安全保障也需要提升，国津软件期待与您携手共赢!
【附录：BSM业务服务管理体系，一只无形的手】
【引言】BSM业务服务管理体系，是一只无形的手、提升着企业内部科技生产力！本文通过一个汽车质量控制系统案例、也是一个服务管理体系BSM的一个实际应用实例, 让朋友们能够见微知著、看出to-B管理软件的一些最新趋势。时代潮流的巨大车轮将始终辘辘向前。
ITIL v3的概念和方法也适用于ITSM及其之外的各类业务服务管理(例如HR服务、财务服务、总务服务、售后服务、生产质量跟踪与控制服务等等)、即BSM(Business Service Management)。正如下面插图里面Wikipedia所说的，BSM是一种 approach (方法)。当然，这些业务服务管理的具体落地实现也都是通过科技工具、IT工具来实现的。所依托的ITIL服务管理方法的基本理念、框架是一致的。对于实现了BSM的企业而言，IT就变成了一个生产力部门，而不是简单的成本中心了。
笔者系国津软件Servitech首席咨询师。
【插图说明】Wikipedia（英文维基百科）对BSM的定义。
【对网上个别的ITSM行业误导文章的反馈评论】
天行有常，不以尧存，不以桀亡！时代潮流代表了天道，其巨大车轮将始终辘辘向前，无人能够改变。
现在网上有人出于对自己技术产品宣传的需要，对国际“服务管理标准“了无概念、甚至完全不懂，就竟然发布文章说自己的“脚本开发自动化运维”(DevOps)能够替代“国际服务管理标准体系”、替代ITIL理念和ITIL系统！嗟夫！这是哪儿跟哪儿啊？
在自云“能替代某理念”之前、是不是先花点时间仔细了解一下，人家那个理念究竟是什么内容、包括了那些内涵、在国内外实际案例里面是如何应用的？不妨放眼看看国内主流企事业单位、欧美主流企业现在应用“服务管理体系”的最新状况嘛！
【ITSM与DevOps】
【DevOps、自动化运维的大前提】这本来是显而易见的：DevOps、自动化运维能够发挥作用的大前提是，只有当：
1. 故障已知，或者批量执行请求已知，
2. 故障原因已知，
3. 解决方案已知，
4. 能够用脚本批量自动操作，
== DevOps才可以实现，否则是不可能的！
所谓“自动化”依赖的都是人已知的东西！
那么，如果以上这些“已知”要素不具备，有未知要素，运维管理该怎么办？肯定还是靠人、靠ITSM流程化管理！对吧。
所以，其实DevOps是ITSM的一个后端延伸。ITSM流程化管理/ITIL系统毕竟是服务管理和运维管理的核心！