“王子”认证与国津ESM落地新场景
重点内容摘要
项目管理水平如何，是一个公司或者团队的“软实力”，需要方法论，也需要相关的管理工具、管理软件。国津团队服务客户的时候、用的是“王子”项目管理方法论。而国津ESM产品也已经适配了该方法论。依据国津客户的反馈以及本文的对照分析，用国津服务地图助力复杂的大项目管理、有极强的专业性。而且这样还有一大好处是，等客户的大项目上线结束之后，并不是说项目管理平台就没用了，相反，这时候平台自带的老本行“服务运营管理、运行维护管理”功能能够继续派上用场。
引言
国津团队用的是“王子”项目管理方法论。“王子II”(英文全称PRINCE II)项目管理国际标准是一个叫做“OGC”(Office of Government Commerce)的英国政府部门发布的，所以相关证书和教材都有OGC字样，如插图所示，当时“王子”认证证书上落款签字的就是时任OGC副总裁的Peter Fanning。国内项目管理认证考得比较多的是美国的PMP，英国的“王子II”项目管理认证在国内普及度相对不太高、听说过的人也不多。现在回头再翻翻看看、发现里面的许多管理思想、甚至一些术语，其实和ITIL或者ISO20000所规范的ESM(企业服务管理)最佳实践的思想是相通的、一致的，毕竟都是英国OGC制定设计的管理标准。
（特别说明）国外的这种原版英文管理标准，里面的字句翻译过来有时候难免产生歧义、或者无法精准表达原意，所以本文为了避免英文概念翻译引起的困惑，不少地方的关键词都加了英文版。也便于朋友们参考，敬请留意。
关于“王子”项目管理体系，内容很多，我们挑选了一些基本的思维与方法(Philosophy and Approach)罗列如下，其中不少概念在本文后面有具体阐述或者涉及到的内容：
* 业务案子始终驱动项目(Project driven by Business Case);
* 计划一定是伴随着授权(Authorization)，
* 成果一定是伴随着汇报 (Reports);
* 项目新阶段开始一定是伴随着评估(Assessment)，
* 阶段结束则伴随着回顾复盘(Reviews)；
* 业务一定伴随着风险(Risks)，
* 决策层次分明(Decision levels are precisely defined)；
* 记录便于追踪(Records for tracking)；
* 项目计划是基于“项目产品”的（Product based planning）。
* 项目产品触发“项目活动”(Activities triggered by products)。
* 事件触发流程(Process triggered by events);
* 整体框架：“流程加元件”(Process Plus Components).
这些其实与ESM (ISO20000 / ITIL)的管理思维一脉相承。
当时2007年笔者用的教材是直接从英国寄来的2005年版的原版英文书，400多页，内容详实、排版美观，堪称是一部“项目管理逻辑宝典”。记得课程结束、后来安排考试的时候，只有四天复习时间，于是每天严格规定要复习100页这些英文内容，结果后来顺利完成计划。除了因为要应对考试，还有一个主要的动力是，这些“逻辑美感很强”的英文内容，让我颇感兴趣。那里面内容逻辑之严谨，令人赞叹不已，简直就是“滴水不漏”。
有个题外话是，2007年夏天笔者在香港的一个培训机构Scoll HK开始接受英国的“王子II”(PRINCE II)项目管理培训的时候，惊讶地发现，培训现场有大幅的海报，但不是关于项目管理培训本身的，而是关于“香港问题少年教育”的，他们利用PRINCE II的先进思想与严谨逻辑、培训教育一些香港的问题少年，让他们理清思考事情的逻辑、理性看待一切事情、提升心智水平，从而更好地融入社会；这一点着实也不失为一个好主意。就像很多香港机构一样，他们也颇重视社会公益方面的贡献。
【以下两个部分的内容标题】
【第一部分：PRINCE II与ESM】
1、关于ESM“场景金矿”发掘的资讯
2、关于项目管理工具——服务地图
3、服务地图如何让“王子”项目管理标准在软件系统里面实际落地？
4、如何严谨计划与妥善管理一个会议项目？“项目产品流图”(Product Flow Diagram)
5、“项目产品流分析”在ESM项目里面的实际应用场景
6、第二个例子：智慧城市、“城市大脑”项目
7、关于“管理产品”(Management Product)与“专业核心产品”
【第二部分：关于“王子”项目管理标准的概念与方法论之节选介绍】
1、关于项目管理的一个基本思维——“流程加元件”(Process Plus Components)
2、关于业务案子(Business Case)
3、关于ESM项目如何科学地启动(Starting up a project)
4、事件触发流程(Process triggered by events)
5、关于是否需要纳入“配置管理”
6、关于项目经理的角色职责
（图注）软件科技研发项目的一个典型例子，如图，关于最新版国津ESM软件的发布，工程师们已经胸有成竹了。腾讯有一个很好的说法，他们十分推崇“自带方法论的团队和IP”。国津团队是自带方法论的。
第一部分：PRINCE II与ESM
【1.关于ESM“场景金矿”发掘的资讯】
ESM, Enterprise Service Management是欧美近几年最新流行的企业服务管理概念，在国内目前完全没有普及。美国的同行Servicenow 就一直在大力推广这个概念。“王子”管理方法论给我们的ESM项目带来两个方面的好处：
一方面，国津团队在为客户们落地这些ESM项目的时候，也得益于PRINCE II的项目管理思想，所以有严谨的项目管理流程与规范，我们是“自带方法论”的团队。这是正所谓“企业文化基因”的一个部分。
另外一方面，ESM的落地应用场景非常广泛，尤其是利用服务地图(Servmap)、影响树等等典型的功能，大到老板可以直观地管理业务漏洞、保障业务持续性，小到“IT配置项管理(CMDB)”等等..... 那么，除了我们过去已知的“业务漏洞监管”、“核心产品质量跟踪管理”、“IT服务与运维管理”、“人事总务服务管理”、“运输管理”… 等等应用落地场景之外，近期国津同事们也发现有客户把我们国津ESM系统、服务地图(Servmap)用于“复杂的大项目管理”。于是我们做了一些调查研究，客户的实际操作场景确实和我们公司比较熟悉的“王子”国际项目管理标准颇有相通之处。所以我们能够在本文中对ESM系统和“王子”项目管理最佳实践的概念联系和 相关管理场景具体落地的方法 稍加总结。
【2.关于项目管理工具——服务地图】如图，国津Ahoova ESM里面的“服务地图”是项目管理的一个很好的工具，尤其当项目内容比较庞大复杂的时候，服务地图能够直接监管到项目各个“流程与元件”(Process and Components)有无纰漏、缺陷故障，并且有自动修复的办法。当然，前提是，项目里面各项“服务”要提前定义相关的拥有者(Service Owner)、资产(Assets)、影响树(Impact Tree)、相关的服务流程...... 等等。读者朋友们可以参考我们最近发布的其它的关于ESM介绍的相关文章、以及国津软件微信视频号里面的相关视频。
美国最大的ESM同行Servicenow颇为霸气地说，同样是流程化管理系统，ESM与其它传统管理软件的一个关键区别是，ESM讲求的是优越的“整体方法论”(holistic approach)，具体来讲，比如“把所有的服务资产组织成一个事情”，其实就是国际上的新概念“影响树”(Impact Tree)。插图是个样本例子，影响树最上面的单个节点是“树根”，是一个服务的入口、例如一个HTTP链接，下面逐层相关联的就是相关的配置项或者资产(CI or Asset)。某个Asset如果不属于任何服务、处于“游离状态”，就没有存在意义；反过来，服务地图中的某一块、即某个服务必定是集合了若干相关联的Assets、并且形成了影响树来支持的，不然该服务就成了“空中楼阁”了。而服务地图则可以理解为集中集成这些Assets和影响树、以及背后的服务流程的统一入口。这样，一张图就搞定了一切（服务地图算法是国津科技的软件发明创造专利）。这些概念是国际上近年来开始普及的比较新的ESM概念。
【3.服务地图如何让“王子”项目管理标准在软件系统里面实际落地？】
ESM里面的关键工具——服务地图、是“服务 + 相关影响树里面的资产集成 + 相关的事件驱动流程”(Service plus relevant assets assembly in the impact tree, as well as the relevant workflows)。其算法是国津科技的软件发明创造专利。将一个大项目里面上一级关键的“项目产品”(Project Products)纳入服务地图，那么每一块“服务”就相当于“王子”管理标准里面说的“项目产品”，而相关的项目活动(Activities)则与“相关的事件驱动流程”有关，把这些项目活动纳入服务地图里面相关的事件管理，并且不同类型的事件自动触发执行不同的流程，那么，每个项目服务（即项目产品）就能够得到顺利完成的系统保障。这样服务地图就是复杂项目管理的得力工具。
【4.如何严谨计划与妥善管理一个会议项目？“项目产品流图”(Product Flow Diagram)】教材里面比较简单的一个实际例子：如图，“王子”管理标准培训教材里面给出的有效组织一个会议的“项目产品流图”，其实也是“项目各级产品及其触发的项目活动关联关系图”，颇为科学逻辑清晰。最底端的终极产品“会议”(Conference)，上一级“项目产品”包括：路演材料、出席人员与发言人名单、会议议程及内容、时间表、选定的会议地点、现场值班人员、会议反馈表...... 等等。这些都由一个选定的会议主题和需要的时间而触发。而这些中间过程的“项目产品”都会触发相关的项目活动，例如，确认发言人、预定地点、确认会议主题、打印反馈表、邮件通知参会者等等......
教材截图这个例子也清晰地说明了本文开头也提到过的：项目计划是基于“项目产品”的，而项目产品触发相关的一系列“项目活动”。这些其实与ESM (ISO20000 / ITIL)的管理思维一脉相承。
【5.“项目产品流分析”在ESM项目里面的实际应用场景】上面教材图片这个例子非常简单。对于一些复杂的大项目，尤其当项目产品很多、而且这些产品触发的项目活动是“需要在某一个较长的时间段重复执行的任务”的时候，这个软件工具就颇为实用。例如，公司要上线一个大型ERP系统的时候，其中一个项目保障就是要妥善处理好用户提出的各种项目实施疑难工单，“工单办理”就是一个很重要的服务，里面自动触发的任务指派流程就是要应对一段时期内重复出现的“办理工单”任务。按照“王子”项目管理标准的概念，“全部妥善解决的工单”就是这个ERP上线大项目其中的一个“上一级项目产品”，这个产品搞定了，项目上线的一个条件就满足了。笔者曾经见到深圳的一个大央企，他们找我们国津咨询ESM软件，就是因为ERP实施过程中、用户工单缺乏管理、而导致公司领导对ERP上线的众多用户抱怨与投诉头痛不已。
【6.第二个例子：智慧城市、“城市大脑”项目】这些项目执行就更加复杂，终端项目产品的“项目上一级产品”涉及的面很广。其中单是“智慧环境”这一块，就包括如下内容：“通过物联网、云计算、大数据、人工智能等技术，实现对城市环境系统的全面感知、实时监控、精准预测、智能调控和优化管理，提高环境质量和资源利用率，减少环境风险和碳排放，推动绿色发展。智慧环境涉及空气质量、水资源管理、固废处理、能源供应等多个方面”。
对于这里面每一项“上一级项目产品”(Upper Level Project Product)需要办理的重复任务或者持续出现的工单、以及需要触发的工作流程、需要集成的各类资产，如果靠纯手工管理恐怕难度都不会比上面说的ERP实施的难度低。要借助系统来管理吗？选ESM与服务地图就对了。用服务地图助力复杂的大项目管理，一定会有显著效果。
而且还有一大好处是，项目上线结束之后，服务地图及ESM自带的老本行“运行维护管理”就能继续派上用场了。所以，这个软件平台有可持续性。
【7.关于“管理产品”(Management Product)与“专业核心产品”】在项目管理过程中，PRINCE II是把“专业产品”(Specialist Product，其实也就是ESM里面所说的“核心产品”Core Product) 与“管理产品”(Management Product) 这两者严格区分开的，例如“项目可行性分析”、“项目启动文档”(PID)、“项目验收建议”(Project Approval Recommendation)等等就是典型的管理产品，这些更像是某个项目阶段的交付物或者输出。尤其在ESM项目是为客户提升核心产品质量的时候，这一点就尤其关键。例如，新能源汽车要实现核心产品、新车型试制过程的质量保障，相关的管理流程就要严格界定里面涉及哪些“管理产品”、并且倒推出相关的“管理活动”(Activities)；这个管理流程是伴随着“新车质量保障”的目标来一步一步实现的。比如，最后的管理产品是“新车质量得到保障”，那么需要的上一级管理产品是“良好维护的零件配置项库及其变更管理流程”、“零件组装规程的变更管理流程”、“良好维护的组装BOM配置项库及其变更管理流程”、“良好维护的零件组装规程库及其变更管理流程”...... 等等。这些“管理产品”本身如果需要严格的版本升级或者版本变更控制，就需要严格按照配置项管理流程(Configuration Managenent Processes)来执行，不然新车质量保障就是空谈。这些管理产品和专业产品(汽车及其零部件)就是分开考虑的。但是二者相伴相生、不可或缺。
第二部分：关于“王子”项目管理标准的一些具体概念与方法论的介绍
下面本文就给朋友们分享一些PRINCE II管理思想的点点滴滴，希望至少能够帮助大家得到一些启发。我们也会举一些例子来说明。这个部分的要点包括：
1、关于项目管理的一个基本思维——“流程加元件”(Process Plus Components)
2、关于业务案子(Business Case)
3、关于ESM项目如何科学地启动(Starting up a project)
4、事件触发流程(Process triggered by events)
5、关于是否需要纳入“配置管理”
6、关于项目经理的角色职责
【关于项目管理的一个基本思维——“流程加元件”(Process Plus Components)】如图，这个形似“八瓣花”的图是原版英文教材里面的。我们会用汉语再做讲解。这种“流程加元件”的思维和ISO20000/ITIL 思维是一致的，二者可谓一脉相承。本文下面讲到的项目管理软件工具“服务地图”，里面也在具体实际操作执行层面充分体现了“流程加元件”的思想。朋友们可以在国津官网或者国津微信公众号里面参阅相关的视频或者文章资料。
【关于业务案子(Business Case)】Business Case是真正驱动项目的，其实是项目存在的理由，主要包括项目的收益价值与成本分析(Benefits and Savings)、风险、可行性、与合理性(Justification)，是在项目管理各个阶段贯穿始终、持续迭代的。项目管理委员会(Project Board)会在每个项目阶段结束的时候、再次评估Business Case、然后相关文件会更新迭代，这个叫做“阶段收尾评估”(End Stage Assessments)。如果在项目过程中的某一时刻，因为成本、风险等等原因、项目的合理性突然被人们发现不复存在了，项目就应该立刻中止。以Business Case驱动项目，是PRINCE II的一个基本思维。
【关于ESM项目如何科学地启动(Starting up a project)】如何有章有法、避免盲目行动？我们一直都认为，PRINCE II这一页就是很好的参考：首先解决项目组的组织问题、确认项目目标、界定如何提供方案，然后第一次评估项目好处与合理性(Project benefits and justification)、以及风险，然后规划一下如何准备项目计划与项目控制。如图。
近年来我们曾经见过极个别的项目，客户一方的项目小组和项目负责人没有指定清楚、或者相关组织者的权限不够，我们就只能想办法沟通解决；如果还是不行、则项目执行恐怕无法保障，最后结果已经不难预料；我们就只能是唏嘘不已。
【事件触发流程(Process triggered by events) 】实际企业运营或者项目管理当中，流程执行不是凭空来的，而是由事件或者时间触发的。而某个时间节点触发一个流程，本质上也是某种预设事件触发的。例如，新建机房项目要求项目测试期间每天晚上9点钟触发一个“例行的机房巡检流程”，这个其实也是“预防机房各项功能出错并且及时纠错”这个预设事件触发的。“事件触发流程”是项目启动的时候、相关的决策者们需要很清楚理解的概念，关于可能出现的各种事件、需要提前作出相关的评估。而在国津ESM软件系统里面，“流程设置规则”(Process Setting Rules)就直观地体现了“事件或者时间驱动流程”，按照系统预设好的规则，某种事件就会自动触发某个流程。这些在专业的ESM系统里面、被定义为一种“自动化”(Automation). 具体的一个例子是，某个系统故障会自动触发相关的“故障修复流程”，是属于服务地图“五个环节”里面的其中一个步骤“自动修复”(Auto Fix)。某个企业“各类故障触发不同的各类流程”相关的规则可能非常多，笔者见过有超过五十个规则的国津ESM项目案例。如图，适用于IT服务管理的服务地图运营步骤。
另外，国津视频号里面有相关的视频，朋友们可以参考。以下这个图是国津ESM系统的“面板”样本，服务地图是中间的一大块。
【关于是否需要纳入“配置管理”】以上这个项目阶段的一个“管理产品”是“初始化阶段计划”(Initiation Stage Plan)。只是，一般而言，这个计划是一次性做好的，不大可能需要后续阶段再迭代，所以无需纳入“配置管理”。
而那些会逐步迭代、升级版本的管理产品，例如“业务案子”(Business Case)，就需要作为一个配置项(Configuration Item)纳入配置管理。
【关于项目经理的角色职责】 这个图呈现的颇为全面：线管理Line management, 资金Funding, 策略Strategy, 沟通Communication, 质量Quality, 产品状态Product status, 变更Changes, 用户需求User needs, 监察Monitoring, 计划Planning, 团队Team work, 客户Customer, 产品对项目需求Product versus project needs.
看了这么详尽的方方面面的清单，笔者深有感触，确实不容易啊！这些角色同样适用于科技公司创业者。创业者首先必须是好的项目经理。按照OGC出的这本教材的指导意见，项目经理重点应该关注“大图景”(Big Picture)，而不是介入某个项目细节的事情。理论上这肯定是对的；但是创业初期，往往不一定有那么好的条件，创业者亲力亲为的事情肯定少不了。这就是理论与实践一个典型的差异。
关于其中一个角色职责“线管理(Line management)”，可能朋友们比较陌生，有个相关的概念叫做“基线”(Base Line)，例如某种产品的一个有意义的“冻结版本”，比如说第一个稳定版本的软件发布。然后后续的产品迭代就在这个基线基础上逐步进行，后面可能还有一个一个的Line。
关于“用户需求User needs”，有一点需要特别说明的，就是项目肯定是有范围的，范围之外的用户需求，属于“用户期望(User Expectation)”，其实也是需要严格管理的；不然项目失败或者亏损的可能性就极大。国内和国外管理软件项目的最大区别是，国外的客户们很多是有“用户期望管理”这个意识的，但是国内很多情况下恐怕是没有的，To-B的软件厂商们聚在深圳参加一个投融资路演会的时候，其中分享的一个方面，竟然就是大家都挺头痛的一个事情：“很多客户们要求项目二开定制”、结果导致项目的边际成本就很高、边际利润则谈不上。当然，预计将来这种情况会逐步好转。
第三部分：有限的披露：深圳某央企实际项目的参考资料
国津某央企客户上线ESM系统之前，项目小组共同制定的项目保障办法、风险分析兹分享如下：
【ESM与ITSM系统实施成功的前提】：
ESM下属的ITSM系统的实施，是一个依赖专业知识经验、需要有强有力推动力的复杂的系统工程，迥异于常规IT项目的实施项目，因此，在项目实施前，需就一些重要因素如全体认知、制度保障等方面进行充分的前期准备或铺垫，项目组成员、参与人员须达成如下共识：
1． 这是值得去做的——在实施本项目时，公司中的每个人都应该就此观点达成共识。
2． 不只是ITIL流程会发生改变—— ITSM实施所涉及的流程梳理优化再造，不仅局限于IT流程或营运流程，它一定会延伸至 IT 组织内各个领域，包括人力组织架构、奖惩绩效、协作机制、工作界面的重新定义等诸多方面。
3． 实施过程中一定会遇到阻力——对变革的抵制是不可避免的，而拒绝改变的动因多是由于担心自身利益的受损。沟通应该是解决这些的重要手段，因此提前形成一个有效的沟通预案，将有助于从认知和制度上来消除阻力的出现。
4． 需要每个人的参与——克服抵抗变革的首选方法就是让每个员工都参与到这件影响深远的工作。即到公司所有业务、人员、部门，并且在未来将会据此持续长期运行下去的运维服务实施流程工作。
5． 需要公司高层态度鲜明的支持和参与——ITSM的实施，也可视为是基于顶层设计的软件系统进行自上而下部署实施的过程，它需要公司高层从一开始就明确的向所有人传达出实施本项目的紧迫性和重要性，以及允许由于变革所致阵痛的发生但绝不中途停止的坚定态度，使公司自上而下快速形成合力共同促成本项目的实施成功。
6． 需要进行教育和培训——为帮助每个人充分认知项目实施的必要性，需要为所有人员安排一次ITIL知识的普及性讲座。对业务涉及人员还应进行必要的深化培训，以帮助其更快的了解ITIL理论，以便充分认知自身角色和责任，更好的配合实施团队提供相关需求和改进建议。
7． 实施过程亦需要成本投入——ITSM项目的建设，软件许可成本仅是其中之一，而咨询类的工作（包括业务流程梳理再造咨询、现场项目实施等工作)的成本投入甚至会高于软件许可的采购投资。
8． 将ITSM实施作为一个正式项目进行管理——将ITSM实施作为项目来进行管理和控制，并根据实际需要和进度要求，对其进行任务拆分，形成多个子项目，并分组执行，从而提高容错性，实现较高的实施效率。
【项目的风险分析和应对措施】
基于采购成熟软件产品进行实施部署的建设模式，本项目的风险应已降为最低——主要存在与实施过程和后期运行阶段。
实施过程的风险主要在于各业务部门的配合程度，因本项目的特殊性，其关键点在于对现有业务的梳理，优化、再造及信息化。因此，需要各业务部门全程参与，配合实施团队进行需求调研、对现有业务逐一梳理建模，进行讨论分析最终形成经过公司确认的新流程、新事项、新业务。因此各业务部门的实际配合程度将是实施效果如何的主要风险点。
后期运行阶段的风险主要在于系统建成后的执行力度如何，是否做到了按标准严格执行业务流程并不断优化调整、持续改进。
上述两方面风险点的有效解决措施，都可通过加强公司高层的重视程度，提升本项目实施的优先级和督查部门的持续监督来解决。
