流程与ITIL在很多人看来，几乎就是孪生兄弟。这样说其实并不确切，在很多领域也是有很强的流程概念，比如号称项目管理王者认证的PRINCE2以及不少其它管理理念。严格地讲，包括我们今天的Process Model主题，也并非ITIL首创，流程管理作为独立的学科也是具有相当的理论深度。但是，我们需要承认ITIL在流程设计上，对于IT服务建设，有很强的方法论指导意义。
    在ITIL V2的时代，其实就有提起过流程（Process）的整体设计概念，但总体来说段落比较散，在一些章节，如a process approach等部分，有过对流程设计关键点的建议。可关于如何建立比较明确的Service Model，在ITIL V2版本的核心出版物中，是没有提及的，或者说没有形成比较直观的图文。但在荷兰专家Jan van Bon主编的《IT Service Management, an introduction based on ITIL》一书中，建立过比较明确的Service Model。而在2007年V3的推出的核心出版物中（Service Design的3.6.4，即Designing processes章节），则正式提出了比较有效的Service Model。两个版本的Service Model还是有微小的差异，我们可以先看一看以下图的对比。

    对于这两幅图，我们不难发现，ITIL V2与ITIL V3对于流程模型理解的共同点有五大组成，Process Inputs、Process Outputs、Process Control、Process、Process Enablers（唯一的区别是ITIL V3提出了Triggers，很明显地区隔了Input与Triggers的功能差异，Triggers为流程的触发者。当然，某些触发完成了触发使命后，也可能成为Inputs之一，比如Incident Management的Request。）。我们则逐一翻译为流程输入、流程输出、流程控制，流程本体，流程关键。我们先解释一下：
    流程输入（Process Inputs）：流程开始的信息输入。例如对于大家所熟悉的服务级别管理（Service Level Management），它的Inputs就包括Business information（业务信息）、Business Impact Analysis（业务影响分析）、Business requirements（业务需求）等，当然还包括服务战略中的不少政策以及来自其它流程的各种信息等。
    流程输出（Process Outputs）：我们可以理解为流程的产生结果或交付物。同样用服务级别管理来思考，它包括各种服务级别的文档、服务组合更新、服务目录等。
    流程控制（Process Control）：是指计划与规划流程的行为，使流程能具备有效性和高效性以及统一执行性。一般是对流程整体的控制与要求。
    流程本体（Process）：就是我们一般所指的流程，比如事故管理（Incident Management）、问题管理（Problem Management）。根据ITIL的术语表，流程可以定义为：为了达成特定目标的一组活动。流程伴随着一个或多个的输入并产生定义的输出。流程有可能包含的因素有角色（Role），责任（responsibilities），tools（工具）以及保证输出的
    管理控制。一个流程在需要的情况下须定义政策、标准、指导、活动、活动指示。
    流程关键（Process Enablers）：不少书刊翻译成流程能动器或流程赋能者。我们可以理解为非流程本身所能提供的资源或能力，对流程的有效并高效实施提供推进与支持。
    经过这样的解释，我想对于流程设计者来说，概念应当会清晰，如果我们还觉得不是很清晰的话，我们可以举一个例子。流程好比是一个球队要比赛，对于球队的自身安排，比如传球线路、谁来发出角球、谁负责领队等等，都属于流程本体（Process）关注的；那么球队的比赛规则、输赢规则、球队评价属于流程控制（Process Control）所关注；球队的入场就好比如同流程输入（Process Inputs）；出场，比赛结果则如同流程输出（Process Outputs）；流程关键或流程助推器（Process Enablers）则好比奖金刺激或者拉拉队。
    对于ITIL V2体系和ITIL V3体系的不同处我们可以看到，有几点不同：
    在Process Control方面，ITIL V3认同ITIL V2设定的流程设计模型中极其关键的Owner，而同时将Goal用Objective取代，取消了QP和KPI，取代的是政策（Policy）、反馈（Feedback）、文档（Documentation）。就笔者角度来说，我是赞成这个变化的，因为这使得流程设计中的流程控制部分更为战略化，将具体的指标完成工作交还给流程本体，而着重在流程实施的指导性层面。而用具有长远目标的Objective代替“功利性”较强的Goal其实表达出V3对流程设计的全面考虑更具体化（进球是Goal，而赢得比赛是Objective，哪一个更有长远意义和战略性意义呢？）。
    相应地在 Process部分，ITIL V3则为ITIL V2时代单纯的活动和子流程定义进一步明确和扩展为Process Metric、Process Activities、Process Roles、Process Procedures、Process Improvements、Process Work Instructions六个特征，这具有很全面也也实际的指导意义！我们稍作翻译这六个点为：指标、活动、角色、进程、改进、工作指示。指标是我们判断流程是否达成的量化方式，活动是组成节点；角色要对流程负责，可能是人，也可能是团队，甚至可能是工具，比如Process Manager主要就是对流程的实施和优化负责。而流程（Process）与进程（Procedures）以及工作指示的关系可以认为是包含关系，即流程由若干进程组成，而进程则由工作指示完成或描述。
    我们举个例子，事故管理（Incident Management）是个流程，这个流程包括的进程可能有服务请求注册、请求指派等进程，对于服务请求支持，我们会有工作指示：比如列出客户细节、检测原始请求等工作指示。可能有不少读者会问，那么活动（Activities）和它们的关系呢？其实这里必然会有重叠性，但是它们关注点并不一样。对于流程、进程、工作指导来说，更多的是指导性的方法，而并非具体的动作。而活动则是明确的动作，所以我们在实际中使用ITIL的方法论来指导工作的时候，我们要理解，活动就是组成流程的一个个节点，而流程、进程、工作指示则是根据不同的层次对这些活动进行方法指导。
    在Process Enables中，ITIL V3则把它最为得意之作，也就是Process Resources和Process Capabilities作为了重要的关键因素！而把在ITIL V2中定义过的Roles“请”出了“助力”系统。实际上，这是优化，而非摒弃，因为Resources可以理解为有形资产，而Capabilities 为无形资产，Roles无论是以人员方式还是组织方式或是工具方式出现，都会被包含其中，但是立场不一样了，是站在流程本体外做的外部推动。
    我们综合比喻一下，流程如果是一个“人”，那么Input是他有什么，Output是他能体现什么，Process的设计是对他自身的修身养性和各种提升，Process Control是外界对他的约束和指导，Process Enablers是外界对他的物质和精神支持。
    当我们对这些概念和因素有了足够的认识，我们其实就具备了设计一个优秀流程足够理论基础。不少学员曾向我诉苦，说不知道怎么来设计一个好的流程。也有人反应，说这么多参数，该怎么来设立呢？其实每个企业、部门都有很多特定的状况，流程是无法套用的，ITIL也仅仅是提出最佳实践的指导，具体的设计当然要根据实际情况来。在此我们不妨找一个生活中的例子来形容，我们可能有八、九个朋友一起去郊游，那么这个流程我们会怎么制定呢？首先，我们确认刚才提到的，也就是 ITIL V3 Process Model提及的所有因素各对应什么，是否有定义。
    Inputs：我们中间有两辆私家车、一共九人，会开车的有三人，零食、烧烤炉、饮料……
    Outputs：郊游的照片，每个人博客上的郊游日记……
    Triggles：Winter过生日，Allen提议大家聚聚。
    Process Control：郊游需要的一系列计划：
    Process Policy：如果临时不到场，将一周后罚请大家K歌一次；准时到场；不得发牢骚。
    Process Owner：寿星Winter是这个活动的最终拍板人。
    Process Objective：过一个愉快的周末。
    Process Documentation：将行程、备忘、安排等全部都打印出来。
    Process Feedback：民意调查。
    Process：郊游的安排：
    Process Metrics：聚会准时到达人数；总体满意率；愿意下周继续聚会郊游的人数；……
    Process Activities：计划、分头准备、碰头，开车到森林公园，骑马、烧烤、合影，开车回家，写博客。
    Process Roles：Owner是Winter，Manager是Allen，负责安排，Maxthon负责跑腿。每个人都可能是Operator。
    Process Procedures：有开车进程、烧烤进程、采购进程等等。
    Process Work Instructions：在开车进程中具有如下工作指示，如：把油加满；检查引擎与刹车；以100km/h速度开车到森林公园；停车；检查是否管好门窗。
    Process Improvements：增加一些Metrics，比如整体费用。并增加一个玩模拟野战的Activity。
    Process Enablers：促进动因和刺激：
    Process Resource：大家刚发了奖金；Robbin买了新车。
    Process Capabilities：大家的积极性；优秀的计划安排；Mary曾经去过，对路线非常熟悉。
    于是，我们发现，通过这样缜密的流程模型套用，我们的安排可以在方方面面做的细腻，同时还很重要的是，对效率和效果达成都做了足够设计与规划。这是生活小事，但是与我们IT工作中的许多事情有着雷同，譬如有许多细节和突发事件可能发生，譬如需要对效率和效果负责，譬如是一个组织在做事情而并非单兵作战等等。但对于生活小事，你具有掌控性，并能得到快速的结果反应。对于流程设计这样一个无论是理论性还是实践性都要求很高的工作来说，读者不妨从生活小事或工作小事做起，形成较强的流程观念，掌握灵活的流程设计能力，并结合许多综合学科，如六西格玛、项目管理，以及自己工作中的实际需求，我相信大家一定能设计出高效实用的流程！

作者：刘颋    上海翰纬信息管理咨询有限公司 授权讲师

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。