Posts tagged ‘管理’

DMO — 整合交付业务的利器,及对客户运营、产品运营的价值

大家都知道PMO = Project Management Office(注:这里指的是交付项目中的PMO,不是研发项目),但是应该没有听过DMO。DMO(Delivery Management Office)是交付管理办公室,是管理ToG/ToB交付活动的组织。

为何要有DMO?交付PMO通常是从项目管理角度对交付活动进行定义和管理,管理的对象也主要是PM。但是,交付活动涉及多条职能线和多种活动,PM、架构、开发、运维、售后等,将这些交付团队视作一个整体、统一管理交付的活动会更加有利于提高交付效率和提升客户满意度,这就是DMO存在的价值。

DMO具体能解决哪些问题?很多交付团队甚至企业存在的问题是:

  • 交付团队为了交付而交付,只是完成商务团队转交的合同,并不清楚交付团队在公司业务架构中的确切作用,而很多公司的管理层及其他部门其实也不是太清楚,这导致了很多业务运行过程中的问题
  • 在交付过程中交付团队与商务、产品等部门之间沟通不畅
  • 交付团队内部各角色间沟通、协作不顺利,未能形成合力
  • 谁能承担起切实的呈现企业产品与服务价值的责任
  • 谁可以提供客户的日常情况,供公司做出商业决策
  • 谁可以提供客户现场产品的一手使用信息
  • 谁能够提供经过验证的解决方案,通常产品团队给出的解决方案不太会考虑各种客户现场的问题

答案十分简单,被充分整合与激励的交付团队可以解决上述问题,而DMO起到的作用就是整合并激励交付团队。

那么,DMO具体能做什么?

  • 定义、管理交付框架和规范
  • 定义、管理交付资源
  • 管理项目组合(也称做项目群)
  • 管理客户组合
  • 支持产品运营
  • 提升交付效率

1. 定义、管理交付框架和规范

交付框架首要目的是说明“我是谁”、“我要去哪里”,也就是清晰定义交付部门在组织内的定位和目标,工作的策略,以及与其他部门协同的原则,工作规范和流程的制定都必须符合这个框架。这个定义的过程中,DMO负责人最好能与公司管理层及其他部门做比较充分的沟通,达成一致。如果这点做不到,就需要在工作过程中不断灌输自己的观点,让别人向自己靠拢。

交付框架和规范的制定一定要从多个纬度加以考虑:

  • 所在组织的战略和业务策略
  • 行业特点
  • 所在企业的组织文化和能力边界
  • 交付团队的使命和工作目标
  • 项目全生命周期
  • 客户全生命周期
  • 产品全生命周期
  • 评价体系

简单来说,

1)交付是服务于组织的战略和业务策略,支持产品落地、赢的客户、获取收入。因为企业目标及其业务所处的阶段不同,每家企业的策略也会有所不同,例如,打磨产品、验证商业模式、赢得战略客户、扩大市场规模、提升客户粘性、提高利润率、挽救业务,等等。面对不同的目标,交付部门应该有相应的组织架构和工作框架,例如是需要多些高水平高薪资的人应便应对无时不在的挑战,还是多招收工资低一些同时经验和技能也相对弱一些的人以降低成本;流程上是应该简单激进一些以快速抢占市场,还是应该保守全面一些,来降低风险。当交付团队面对管理层的各种要求时,略微分析一下公司的业务情况,就能理解了,甚至能预测公司老板的行为。当然,这种方法不仅交付团队能用,其他团队一样适用。

2)不同的行业有其特点,成熟行业、新兴产业、ToG、ToB,等等。成熟行业通常会有成熟的模式和规范,而新兴行业则需要更多的摸索,缺少业界统一的标准;ToG行业重视政府关系,ToB行业里帮客户赚到钱则是王道……面对这些不同的要求,交付团队的工作模式和人才结构都会有所差异。

3)所在企业的组织文化会深刻影响所有部门包括交付团队的工作方式、沟通方式、工作效率。例如,一个讲求互信高效的企业,可以大大简化流程和检查节点,而在一个喜欢甩锅的组织中,流程不得不包含自我保护的成份,这也会导致流程的冗长和效率的下降。企业的能力边界则包括组织能力和产品能力,交付团队需要在实践中摸清这个边界。在边界内做事相对安全,不能向客户过度承诺边界外的需求。为了提升企业的能力,有必要突破边界,不过,产品边界通常(不是绝对)要靠产品团队来突破。但是,交付团队必须要认识到自己在突破边界,其做事方式与在边界内活动差异很大。

4)交付团队的使命和目标是用来凝聚交付团队的重要方式。适当的使命感和目标可以增强团队成员的自驱力,降低管理成本,提高敏捷性和创新性。交付团队可以有哪些目标?以下为一些选项:

  • 产品落地。公司一般愿意开发和销售标准产品或平台,因为边际利润高。但是,在ToG、ToB市场里,客户的需求是差异化的,产品或平台与客户需求之间通常存在着一条鸿沟。越新的技术,鸿沟越明显(详见关于AI的另一篇文章     )。填平鸿沟的方式无非是客户自己定制化开发、公司找第三方定制化开发、公司自己定制化开发。不管哪种,都需要交付团队的支持
  • 呈现公司产品与服务的价值。客户最初接触公司的途径通常是广告和销售,看到的也是PPT或产品演示,并不确切知道产品到底能给他们带来什么样的价值,毕竟广告和销售会夸大“功效”。直到产品被交付和部署进客户的环境,客户才有机会真正看到产品的价值,但是能看到多少,很大程度上取决于交付的方式。同时,交付团队是客户在实际工作中接触最多的人,他们的表现代表着公司的形象,他们为客户解决的问题反映公司服务的价值。客户是否愿意持续购买公司的产品和服务,一方面取决于产品本身,一方面取决于他们享受到的服务。这其中,产品的价值不是产品自己说了算,而是客户看到和感受到的,这就需要交付团队来帮助呈现。
  • 帮助客户成功。客户达成业务目标,才有动力和预算继续购买公司的产品和服务。坑蒙拐骗只能做一锤子买卖。如果设定这个目标,就一定要真诚,听起来很滑稽,是吧?因为在实践中会发现,客户成功与公司的短期目标有时会存在冲突,如果没有真正地将客户放在心中,很容易走偏。
  • 帮助公司实现可持续的收入。公司毕竟要盈利,但如果能够做到前三点,可持续收入的目标就不难实现了。这里说的“可持续”,是在一个领域里、一群客户身上,持续获得收入,而不是打一枪换一个地方。那样,即使不断有收入进来,也是不健康和不可持续的。

5)DMO的管理对象是项目,自然要考虑本公司的项目全生命周期如何定义,分哪几个阶段;项目服务的对象是客户,客户也有其生命周期;提供服务的工具是产品,产品也有其生命周期。项目、客户、产品都有各自的生命周期,有不同的阶段,每个阶段有其特性,需要不同的工作方式,三者不同的阶段组合在一起,再叠加业务所处的阶段,交付团队的做事策略和内容就比较清晰了。

6)流程是否适合业务需求,流程执行情况如何,资源是否满足要求,甚至业务情况如何,这些都需要一个评价体系,确定评价的环节、评价指数类型和参考值,并呈现决策视图,方便DMO实时了解情况并做出调整:对项目进行干预,调整资源投放。

如果可能,可以定义一下交付的工作和任务内容,并针对每项内容做个自我评估,与业界的差距,以及重要性。这个评估每年做一次,其结果可以作为团队建设的重要输入,也是对能力边界的一个认知。

与PMO不同,DMO制定规范和流程时不仅要针对项目管理活动,也需要扩展其范围到开发、运维、售后、服务管理等,以及与商务、产品、财务、供应链等部门的无缝衔接。必要时,还要影响其他部门的流程制定。流程的制定可以参考 — 流程“河”

2. 定义、管理交付资源

交付资源是交付活动的执行者,他们的技能类型、高低、数量和在项目中的分布,对于交付的质量、效率、速度、成本都有重大影响。

因此,DMO需要根据业务需要,与职能线共同制定专家模型、技能栈和级别,以及不同级别对应的技能分数,然后对团队做一个评估和摸底,再根据结果安排培养计划。

从个人技能来说,很多企业有一个误区,觉得越专业越好。如果在传统的行业、传统业务中,这不是什么问题,因为业务、流程都很稳定,对创新的需求少,每个人就是一个螺丝钉。但是在日益变化的环境中,业务在快速迭代,工作内容和流程也不成熟,一个人经常面对各种情况,必须具备多种技能。传统的要求,就像以前的陆军,每个岗位职责和技能要求十分分明;创新型业务其实要求特种部队一样的员工,每个人都具备多种技能,能够独立应对各种突发事件,只不过每个人各有专长。

例如,如果PM懂一些架构、开发、运维的知识,他很多时候也可以独自与客户讨论或处理技术问题,不需要每次都带技术人员同行。如果运维具备一些项目管理以及与客户沟通的技能,也可以独自去客户现场,自行管理简单的项目。这样可以显著提高工作效率,降低成本。另一方面,大家具备相互领域的知识,讨论的效率也会更高,更容易相互理解,达成一致。同时,多维度的知识相互碰撞,更容易激发创造性。

顺便说一下,当代教育届已经意识到目前的培养专才的主流教育只适合传统的工业社会,无法适用于创新性社会,未来的人才在知识层面必须是通才。对于将“创新”挂在口边的企业,如果依然延续以往的人才机制,将人视为工具,就很难将“创新”落实到实际中。

除了个人的技能,人才分布也是资源管理中的重要事项。不同的业务需要不同类型和不同级别的人。例如,一家公司内,成熟业务线的交付难度应该相对较低,效率相对较高,同样的业务量,需要的人数应该少一些,人员级别可以低一些。新兴业务线的不确定大,工具和流程还在创建或磨合中,需要的资源相对多一些,需要更多的有经验的人员(级别高一些)。根据业务线的情况,分析人员投入的分布,就能识别一些人员配比的问题,提前布局或实时调整。下图中,成熟行业与新兴行业的PM配置就有疑问,技术人员的级别比例就比较合乎清理。

3. 管理项目、客户组合(portfolio),支持产品运营

项目组合管理是企业战略的一个载体,通常掌握在管理层手中,不过DMO毕竟有丰富的一手信息,可以辅助管理层进行项目组合管理。

项目组合应当服务于组织的长期战略和中期策略,管理内容涉及项目优先级、项目顺序、项目资源分配等。DMO(也包括一些PMO)应明白上述情况,然后监测项目的信息与状态,例如项目类别(尤其要区分POC和合同项目)、项目等级、项目健康状态、项目所处的阶段(按照项目生命周期)、项目当前milestone、项目区域、项目对应的业务线,决定哪些项目需要介入,哪些需要投入更多的资源,哪些需要提交给管理层讨论。同时,还可以从总体分析项目群状态,例如上述项目的百分比,还可以按照时间轴来分析项目群的发展趋势,是否需要对资源进行调配等等,进而,也能看出公司的业务发展趋势。

每个项目背后都有一个客户,所以交付团队也会有这些客户的一手信息供DMO收集,例如,最终客户名称(不是代理商),客户行业,客户区域,客户所处生命周期阶段(这个需要特别定义),客户健康状态,客户处实施了几次项目,客户都购买或部署了哪些产品,友商在客户处的情况,等等。这些信息可以分析得出公司的市场情况,业务是否聚焦,客户忠诚度,核心客户比例,以及客户离开的成本等等。客户的情况,对于项目组合的决策也会产生影响,例如,不同生命周期阶段的客户的项目出现问题,其重要性是不同的。这些客户信息也会有益于客户画像,帮助相关的面向客户的部门(可能就是交付自己,也可能是销售)及时跟进客户情况,处理潜在风险,识别潜在需求。

交付过程中一定会知道公司产品的使用情况,从产品纬度,可以知晓产品在哪些行业发展得不错,哪些行业还比较欠缺,哪些产品组合销售得比较好(这个可以帮助纠正解决方案的偏差),产品哪些功能比较受欢迎(这个数据还需要进一步核实原因)。这些都是对产品运营有价值的信息。

以上这些信息都可以用dashboard的形式呈现。

4. 提升交付效率

提升效率可以从这几个方面入手:

  1. 持续优化流程。每个流程的制定都有其适用范围和条件,一旦这些条件发生变化,就应该更新流程。同时,推广流程时,不能为了推广而推广,一定要和业务实践结合起来,确保流程能够促进业务,也要让流程的实施者明白这个道理。这个过程在初期会比较痛苦,但是越往后会越感受到这样做的好处。
  2. 结合移动、远程办公工具将重复性的办公工作自动化。这个过程中,一定要避免工具产品经理的认知与交付业务的脱节,也不必要追求大而全的工具,毕竟工具是为一线交付工作服务的。因此可以尽量采用已有工具,如果自研,也要坚持敏捷与快速迭代的方式。前面提到的组合中的数据的采集与dashboard的生成,都可以在工具中实现。同时,工具架构设计也很关键,不仅要将各个模块放进一张全景图里,还要将工具与流程对应起来,明晰工具和流程之间的关系,然后沙盘演练一个业务在不同工具间流转是否顺畅。
  3. 将面向客户的交付动作尽量工具化,例如,重复的定制化开发需求可以做成一个半成品,工堪检测和问题诊断的工作做成脚本或小工具。在交付团队内培养开发的技能很重要。

结语

标题虽然是讲DMO,其实花了大量篇幅介绍交付团队的工作,正是因为交付团队对于很多产品或平台公司的重要性,如何整合交付团队、发挥交付的价值才显得十分重要,也就有了DMO存在的必要性。

流程“河”

在公司内部有很多流程,它们的作用应该是什么?只是应付各种审计,给一线人员增加负担,做各种报表?错!如果一个流程只是实现上述功能,它们就应该被立刻废弃。真正的好的流程一定要能够增加价值。

流程本质上是组成业务的基本单元,也就是说,每个业务都有一系列的流程所组成。而流程,则是由跨越一个或多个组织的活动组成,这些活动利用一个或多个输入要素,对其进行转换和增值,最后向内、外部客户提供一种或多种产出。

因此,流程的顺畅与否,流程过程是增值了还是增加了太多的成本,对业务的结果具有重大的影响。

可以用河流来比喻流程。河流会流经不同的区域,每个区域可能有支流汇入其中,同时有人疏通河道,有人清理污染,也会有蒸发渗漏,有人偷排污水,有人抽水灌溉农田,还有人筑起大坝。当河流从源头流入大海,水量和水质决定了大海的质量。这其中,支流、疏通河道、清理污染就是对流程的增值,蒸发泄漏、污水、抽水灌溉、大坝、疏通河道和清理污染的人力则是成本,大海就是为顾客提供的产品或服务。

一个流程会有不同的节点,会有若干活动。如何评判这个流程是否能够促进业务,有必要分析一下这些节点和活动带来的“收入”和“成本”。例如从产品开发到上市交付过程,大的活动会有需求分析、开发、测试、交付等,节点会有需求评审、发布评审、上市评审等,涉及的部门会包括市场、产品、开发、测试、财务、法务、交付、售后等,流程的终点是外部客户。

所有活动投入的人力都是成本,在各个活动和评审环节所停留的时间也是成本(机会成本),得到的收益有需求澄清、代码本身、代码质量提升、产品质量提升、提升客户体验、规避财务和法律风险等。当把这些收益和成本都梳理出来后,就比较容易判断是否满意这样的投入产出比(ROI),哪些步骤和环节的成本大于收益,应该被优化甚至砍掉。又或者,一些流程和环节在业界是成熟做法,但为什么这么设计,这里面有什么关键注意事项?如果不理解内在原因很容易流于形式。如果按照前面的方法来做分析,就能这个弊端。

流程“收益”与“成本”分析示例

例如,一个成熟的场景,成熟的客户,法律风险相对较小,这时候如果花费过多时间(成本)去评估法律风险(收益),就是负收益了,此时可以考虑换个更快速简易的方式,甚至极端情况下取消。

又例如,在上市时间紧迫的压力下,是否应该减少需求分析、测试和评审所花的时间?如果减少这些时间自然减少了相关成本,但是有可能也会减少相应的收益,这样的交换是否划算?把收益和成本梳理清楚,摆在决策者的面前,这样他们就能更准确地做出判断。

流程“回报”评估表示例

在现实中,不少流程或环节的设立只是为了突出相关部门的存在感,对业务并没有实际的价值,这种分析方式可以帮助识别和评判这类流程或环节的合理性。

有人可能会希望有个定量的方式来更方便的评估,很遗憾,这个比较难。这种方法只是提供了一个更细致的评估和分析流程表现的方法,不能完全自动化。从个人观点来说,除非已经有成熟的业务模型、成熟的组织体系,否则试图完全量化都是没有意义的行为,尤其是在快速变化的内或外部环境中。

前面提到,一个业务是由一个或多个流程组成的,流程和流程之间可能会存在大量断点,这也是很多流程多的公司容易犯的毛病。导致流程之间出现断点的最主要原因,就是这些流程由不同部门的不同人负责,而他们缺乏有效沟通,同时也只关注自己范围内的事情。

往更高的方面说,一家公司的诸多业务之间可能存在关联关系,例如LTC、产品开发、生成、供应链管理、交付、客户服务、售后等等,这些流程之间存在在依赖或互为输入输出的关系。但经常的情况是,不同业务、不同部门之间的合作并不顺畅,导致流程之间存在断点。如果要理顺公司的大部分业务,尽量排除流程断点,一个比较好的方式是把所有流程放进一张全景图。就像一张全国地图呈现所有河流的走向、关联关系,然后模拟实际场景运行流程(就好像开个小船顺着河流巡游),这样就比较容易发觉它们之间连接的顺畅情况以及可能的问题。

流程全景图示例

解决这个问题的一个可行的方法,就是有人从总体上负责(流程架构师)。他至少要做好三件事:

  1. 定义总体流程架构,有哪些流程,流程的范围和目的是什么
  2. 定义流程间的接口
  3. 各流程就绪后,按照业务的情况,沙盘演练,把各种场景都跑一遍,这个过程中,也要关注流程的增值情况

当然,这也要求这样的流程架构师能够有足够的影响力或权威,并关注细节,以获取相关的信息,并推动流程变革。