Wiki source code of 1.3.4价值链驱动的服务模式变革
Version 6.1 by superadmin on 2020/06/15, 16:45
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | 很多年前,流程管理成了企业业务变革的良药,“以客户为中心,以流程为导向”一度是企业管理的最佳方法。 | ||
| 2 | |||
| 3 | |||
| 4 | 但是随着流程的模块化,无论是对 ERP,还是对 ITSM,大家都出现了迷惘——本来大家期望流程打破不同部门之间的竖井,但没有想到,流程与流程之间也开始形成了竖井。另外一方面,以ITSM 为例, 许多业务部门的人员非常不认同其复杂的流程关系,更希望自己的业务请求变得简单明了。 | ||
| 5 | |||
| 6 | |||
| 7 | 于是,价值链这种“端到端”的模式,开始给予大家新的想象空间,因为通过价值链,开始真正实现了价值的传递,所有的活动对业务人员和后端服务支持人员来说,都是透明的,也都是能参与的。 | ||
| 8 | |||
| 9 | |||
| 10 | 我们不妨举个例子:在一家工厂里,仓库中采用物联技术管理叉车运载,但是 WiFi 出了故障,这样所有的物流业务运作都因此受损,无法及时交货。如果按照以前的思路——把故障报给服务台, 然后再按部就班处理,仓库经理和叉车工都会被隔离在流程外,他们会很焦虑,这也是传统 ITIL 经常被人诟病之处。 | ||
| 11 | |||
| 12 | |||
| 13 | 在这里,不妨也说一下 DevOps,这些年 DevOps 明显被“妖魔化”了,其实 DevOps 在敏捷的开发测试运维一体化、基于精益的持续交付等方面都表现卓越,但这并不意味着 DevOps就一定擅长解决服务交付的问题。尽管在服务管理中,DevOps 是后面提到的发布管理(Release Management)的最好伴侣。 | ||
| 14 | |||
| 15 | |||
| 16 | 那么采用服务价值链来再造这个服务流程吧。我们用列表的方式来简化这个流程(见下表)。 | ||
| 17 | |||
| 18 | 表1-1:服务流程价值链样例 | ||
| 19 | |||
| 20 | [[image:1592210742578-969.png]] | ||
| 21 | |||
| 22 | [[image:1592210615139-963.png]] | ||
| 23 | |||
| 24 | [[image:1592210646948-403.png]] | ||
| 25 | |||
| 26 | |||
| 27 | 我们采用了一个最简洁的例子进行剖析,由于并没有涉及服务的新建或调整,所以有关获取构建、设计转换、产品服务等环节都没有提及。在这里,我们还意识到一个事实——ITIL 4 已经不再提倡采用简单的事件管理、变更管理等竖井式流程来驱动服务过程了,而是把这些流程里的方法作为“实践(Practice)”来应用,它们通过支撑价值流活动的实现来实现对价值的贡献。 | ||
| 28 | |||
| 29 | |||
| 30 | 其实这个方法并不是空洞的理论,在作者多年的 IT 服务管理咨询项目交付过程中,我们考虑到不同组织文化、不同业务模式,早就采用了类似的思路去设计流程,用中国人常用的话来说,就是“落地”。 | ||
| 31 | |||
| 32 | |||
| 33 | 当然,这个方法的推行,还需要一段时间,目前的主流工具、国际标准(ISO20000)都还是遵循流程的架构来进行服务管理,不过我们相信,这种 IT 服务价值流的方法很快会得到践行。 | ||
| 34 | |||
| 35 | |||
| 36 | 下面,我们就来了解一下 ITIL 4 提出的实践(Practice)吧。 |