组织转型,10件你必须知道的事

[摘要]当今,世界上大多数组织正在经历一个重要的、史无前例的重组。作为组织中转型的开创者,面临着未知、艰险和迷茫。虽然没有放之四海而皆准的统一路径,但在实践中总结出的10条金玉良言或许可以让你的转型旅程少走些弯路。

根据字典释义,开创者是“第一批定居或者开发某个区域并为他人准备好可以随之进入道路的人”。仔细想想,这个开创者的角色,和我最近经历过的大规模组织转型中,旨在把整个组织从大规模IT项目转变成为真正客户导向的引领者非常相似。

听起来很牛?别傻了!当第一不是简单的事,也并不意味着自由;更多的是未知、艰险和迷茫。

首先,它可能非常让人沮丧。没有使用指南、没有操作手册,连一个从哪里开始的框框都没有。你需要深入一线亲自实践,做好犯错的准备。大多时候,你一边前行,一边思考下一步该怎么走。

“有意义的变革,就像旅行,好不好来自于学习和收获了什么,而不是你走了多远。”

无需刻意研究,我们就能看到世界上大多数组织正在经历一个重要的、史无前例的重组。高速的变化、市场的无情压力,让组织很难再有自己的“柯达一刻”,迫使组织打破常规,寻觅更好的组建方法。

最为重要的是,为客户提供价值,是大多数组织存在的唯一原因;组织正努力向“以客户为导向”转型。但究竟怎么开始呢?你如何开始重新思考一个组织最基本的交互、思维和行为方式? 并没有一个放之四海而皆准的答案。每个组织都有自己独特的文化、客户以及工作方式。所以坦率地说,如果有人告诉你他们找到了标准答案,他们很可能在说谎。

我过去犯过很多的错误,也不断从过去和现在的前辈们那里去学习取经。据我所见,虽然没有明确的方法,但幸运的是,有一些普适的原则。

如果你要在组织里引领转型,也希望你的后来者能成功接棒,以下10条是你必须知道的。

1. 创建一个专门的、负责转型落地的团队

总是从你打算如何展开入手。让专门的人去做,全力以赴,转型就是他们唯一的工作。让组织里最资深的和最有影响力的人领导转型至关重要。选择在你的组织中有影响力的人组成转型团队,且由实干家和领导者合理混编而成。

最后,确保组织中所有职能部门都有代表,比如人力资源和财务这样的共享服务部门。鉴于转型会牵扯到到你组织的每一个部分,所以让相应部门的人来主动领导转型。

2. 描绘一个简单的的愿景和蓝图

图1 转型愿景

光说并不够——只是简单地说说要变为“客户导向”,或说“要以客户为中心”远远不够。人们需要知道,新的运作模式将会是什么样,以建立初始的信心。

使用一个简单的可视化方式,将组织美好的未来描绘出来。相信我,胆怯之人做不成这事。这很困难,但是如果做对了,将使整个组织拥有共同的目标和必将成功的雄心壮志。

3. 致力于学习过程,而不是只想跑到终点

尽早打造一个学习型文化,而不是忙于绘制甘特图[1]。组织转型是一个迭代的过程;你将通过尽早验证-学习环来获知什么方向可行,什么应该放弃。以实践证据为基础的学习,可以更好地辅助决策,并为组织下一个验证点提供方向。

4. 确保高层管理团队的全力支持

客户看不见,也不知道,或者说,根本不在乎你组织内部是否各自为政,甚至你们的高管是谁。但是,你需要知道。

你刚开始就会遇到障碍,后面还会遇到阻力。没有来自高层领导们的承诺、支持和改变,变革几乎是不可能的。

转型不仅需要融入到组织运作节奏中,而且也应当进入高层领导的工作日程,他们必须经常碰头讨论转型相关的问题,并专门为此腾出精力。他们必须能够移除障碍,帮助组织转变——从客户需要接触组织内的各个单点,转变到完全无缝的客户体验。

5. 可视化所有工作

将组织中的工作可视化,是艺术和科技结合的学问。有效的可视化,有助于揭示组织的瓶颈、低效能点。

最简单最有效果的起点,就是将你组织内所有工作可视化在物理墙上。某种程度上,这是让“僵尸现形”[2]的一种手段。十有八九,直到你把那些东西从电子表格里拿出来放在某个地方,你才能看出这里坑有多深。更重要的是,在“墙”边进行讨论,可以得出有价值的洞见,并使决策过程显而易见。

6. 大处着眼,小处着手,快速迭代

图2 产品发现-定义-交付

尽早在小范围内采取行动,通过实践中获得的数据来验证你的方法。找一个小团队,授予特权,不必受限于严格的KPI、年度考核、传统角色职责,给予其充分的自由空间。选择一个客户成效作为目标,让了解相关工作的人做负责人,并尽早展示组织如何改变能达成此成效。

不受约束、一心只想“只交付对客户有价值的东西”的团队,必将茁壮成长。进行学习和总结,将那些行之有效的方法扩展到更大范围、规模化,那些无效的方法则果断抛弃。

7. 走出办公室,现地现物

去现场、观察、探索、学习。转型中的团队,除非刻意去保持联结,否则可能很快就不再沟通。在自己团队以外投入时间至关重要。

走到客户面前、走访其他团队、访问其他正在转型中的组织,将确保转型团队与实际工作保持关联。这样,扎根于数据、洞见和实际观察的决策,将会更为明智和有实效。

如果你想改变工作方式,那就要走进其工作现场,深入了解做这份工作的人。

8. 度量工作成效

图3 度量成效

我们用度量来增进理解并学习。度量对于了解组织是否正接近要实现的目标、是否在交付对客户有价值的东西至关重要。从一个小功能,到一个业务目标之间应该有一条对齐线。

研究如何有效地度量工作成果,并可视化,将对话的焦点转移到衡量客户价值,而不是付出的成本,然后基于学习到的经验采取下一步行动。

9. 雇一个会讲故事的人

讲故事这门艺术存在好久了。越来越多的组织开始放弃无尽的幻灯片演示和季度评估;取而代之的是,他们选择传播有说服力的故事。

在转型团队中有一个会讲故事的人,作用是巨大的。他们会一次又一次地去沟通、安抚和激励,传递转型的声音。一个关于“为什么要转型”的阐述,将激励人们采取行动,其产生的力量远比任何20页的幻灯片柱状图都有效。

10. 让领导者们安全变革

Eliyahu Goldratt(以色列企业管理大师)说得非常好,“先告诉我你将如何考量我,我才告诉你我如何行动”。某些时候,你需要解决一大团乱糟糟的绩效管理过程。你不能期待依旧以过去的方式来评估员工,却产生不同的结果。

两个关键变化需要发生。首先,针对你的组织,开始度量什么对客户是重要的;其次,从针对个人度量转变到针对团队度量。改变员工评估方式将改变其行为。

做一名转型开创者是非常艰难的。知道什么情况下可以做何种准备,会让这条路稍微变得相对容易点。但是也不要感觉太安逸了,有价值的变革就像旅行,好不好在于你学习到了什么,而不是你走了多远。

译者注:

  1. 甘特图:常规项目管理使用甘特图来跟踪项目进展情况。
  2. 僵尸现形:指组织中瓶颈、低效能点暴漏出来。

作者:Sue Visic, ThoughtWorks总监咨询师

译者:张岳,ThoughtWorks资深咨询师

Share

新加坡政府的数字化之路

在世界经济论坛发布的2014至2015年全球竞争力报告中,新加坡政府位列 “全球最有效率政府排行榜” 第二名。世界经济论坛评估全球144个国家政府的效率和竞争力的标准,在于政府开支的浪费情况、政府管制的负担及政策制定的透明度。

在最新的世界银行 “最容易经商的国家” 排行榜中,新加坡位居第二,在过去十年,新加坡一直高居第一。

2006〜2015的十年间,新加坡人均国内生产总值从全球第七名(六万美元)提升至第四名(八万五千美元)。反映贫富差距的基尼系数,也在过去十年间逐渐下降。

政府的效率、做生意的难易度、居民的生活质量,很大程度取决于政府为居民、企业提供服务的质量和效率。在这个信息量巨大、环境多变的时代,新加坡政府之所以能高效运转并取得一系列瞩目的成绩,科学技术无疑是关键要素之一。

新加坡政府数字化的历史

新加坡政府的信息和数字化始于1980年国家信息化委员会的成立(Committee for National Computerisation)。成立该组织的目标是使用信息及通讯技术来提高政府公共管理效率,主要专注于工作自动化以及办公无纸化。到了90年代,重心逐渐转向在公共服务内网集成和共享数据。

进入21世纪,政府对数字化的重视程度上升了一个新台阶。2000〜2003年间,新的电子政务计划(e-Government Action Plan I)出台。其愿景是在全球经济日益数字化的进程中,将新加坡发展为拥有领先电子政务的国家。

时任公务员首长的林祥源(Lim Siong Guan)先生还特别指出,电子政务(e-government)不仅仅是增加计算机设备、在网站上公示信息、象征性地为政府服务加个“e”,其核心是利用信息技术带来的优势,重新对政府工作模式进行全方位思考,重新设计工作流程,大幅提高政府对个人及企业服务的质量和效率。

自90年代末开始,全球互联网经济的发展呈现指数级增长。旨在创造领先电子政务的新加坡政府,在第一个计划启动三年后又推出了新的计划(e-Government Action Plan II),该计划的愿景是在2003至2006年间,打造一个网络化的政府,通过为用户提供易访问、集成化、有价值的电子政务服务,将国民紧密地团结在一起。

2006年,iGov2010年愿景诞生,计划从一个集成化电子政务的政府,发展为高度集成管理的政府。通过信息技术连接民众,提升服务满意度。该计划要求所有职能部门改进政务系统的后端流程,增强以用户为中心的服务能力。

(图片来自:http://t.cn/RNRPwwo)

最新的一份覆盖2011至2015年的电子政务总规划中,数字化道路由自上而下 “政府对用户” 的方式转向 “政府与用户” 。该计划最主要的改变在于,政府、民众、私企将展开合作与互动,共同为国家和民众创造最佳的信息技术解决方案。2014年,政府宣布由GovTech(政府科技部)启动 “智慧国家” 工程,通过全国范围的传感器进行数据采集和分析,更好地掌握各项目事务(例如交通状况、空气质量)的实时信息。

( 图片来自:http://t.cn/RNRPwwo)

成就与不足

三十五年间,新加坡政府紧跟全球信息技术发展的节奏,不断调整电子化政务发展的规划设计,从实现自动化、到追求卓越、到集成化管理,再到政、民、企合作创新。2003年政府引入了 “SingPass ID”,个人可以一站式登录访问政府所有在线服务。到今天,用户已经可以用SingPass 获取六十多个政府部门的在线服务(例如申报个税、申请政府祖屋、查询社保),无需创建多个账户。同时,企业登记注册流程也全面自动化,一般情况下完成整个在线操作仅需15分钟,注册审批通过后会自动通知用户,企业主无需进行进度查询。

政府在数字化的进程中,也在逐步提升适应外部变化的能力,更加关注用户体验。例如人力资源部在2014年开始新建的外来家政佣工签证管理系统中,引入了用户体验评估机制。新系统是所有政府机构中第一次使用敏捷开发和项目管理方法的系统,做到了快速上线、持续交付、收集反馈以及持续改进。上线后,呼叫中心的客服电话减少了30%,用户不通过中介的自服务比率提升了15%,72%的参与反馈的用户为使用体验打了满分。该系统也在2015和2016年获得多个政府奖项。

在ThoughtWorks新加坡分公司工作的一年半里,接触到不少负责数字化项目的新加坡政府官员,其中不乏打破常规、承担风险、积极创新的领导人。我们经常在一些创新与科技会议上看到他们的身影,在谈话中听到他们对用户体验的关注,看到他们在组织中尝试新的方法和技术,并探讨组织变革和转型的路径以适应未来发展。GovTech(政府科技部)在从前身的IDA(信息发展局)分离转型后,更是将 “Agile, Bold, Collaborative”(敏捷、无畏、协作) 定为新组织的三大核心价值。

在科技迅速发展、用户期望值不断提高的今天,庞大的政府系统要完全跟上时代的脚步,也并非易事。李显龙总理在2017年2月24日的一个创投峰会上提到,“虽然我们在2014年末启动了 ‘智慧国家’ 计划,但其进展低于我们的期望。”

为了促进 “智慧国家” 计划的快速实施,2017年5月1日起,“智慧国家及数字化政府团队” 被纳入总理办公室直属管理。

但是,我们也观察到,政府部门以及国有企业的采购流程还未能较好的支持顶层期望的科技创新。例如,对定制化IT系统,采购方常常用超过半年的时间进行预先需求设计,以固定价格方式进行招标,再用几个月的时间来评选、确定服务商。从想法的产生,到落地实现,少则一年,多则数年,这与当前科技发展的速度形成强烈反差。此外,在固定价格合同方式下,服务商为了降低风险和成本,通常以拒绝变化、固定架构的方式来建造政务IT系统,减少了快速尝试、持续改进的机会,且为系统未来的升级改造埋下高额技术债务。

未来的挑战

新加坡这个城市之国仅有土地718平方公里,常住人口540万,94%居住于高层公寓,其中82%为政府祖屋。在这个人口密集且对政府服务高度依赖的国家,高效和智能的城市交通、良好的居住环境和医疗服务与这个国家的全球竞争力以及民众生活质量密不可分。

由于国土和人口数量较小,如果纯粹焦距于国内市场,提供数字化服务的企业发展空间非常有限。加之数字化项目通常投资巨大,对于本国特定、较难在别国直接复制的数字化服务,营利模式不明朗,对初创企业、私营企业及投资者没有足够吸引力。最简单的对比是,中国的巨大市场能够不断地吸引私营、初创企业和投资者开拓各种领域的科技创新和数字化服务。而新加坡特殊的地域特点进一步增大了政府提供多领域数字化服务的压力。

新加坡也是全球老龄化趋势最严重的国家之一。2012年60岁以上人口占15%,到2050年,60岁以上人口将超过目前老龄化最严重的日本,达到38%。从国际趋势看,为了提升生活质量和寿命,养老方式正在逐渐从集中化转向社区化。如何让庞大的老龄团体在社区内舒适、安全养老也成为这个国家未来发展的巨大挑战。

智慧国家计划

智慧国家计划旨在使用科技为民众创造更加舒适且充满意义的生活。通过利用互联网/物联网、数据分析和通讯技术,提升民众生活质量、增加商业机会、促进各种族团结。

智慧国家计划包括五大重点领域的数字化工程:交通、居住环境、商业效率、医疗和养老、以及政府服务。整个计划并不全部依赖于政府的工程建设。政府通过提供必要的基础设施、测试环境、海量数据、培训津贴、科研支持以及各种优惠政策来积极鼓励个人、初创企业以及成熟企业创新和实施技术方案,与政府各部门一同打造新加坡的智慧未来。

(图片来自: http://t.cn/RNR7Z9N)

智能时代的政府数字化

世界经济论坛创始人兼执行主席克劳斯.史瓦布先生于2016年初出版了书籍《第四次工业革命》。这一次革命的核心进程是智能化和数字化,而且正以前所未有的态势和速度向我们席卷而来。一系列的新兴科技包括机器人技术、人工智能、纳米技术、量子计算机、生物科技、物联网、3D打印和自动驾驶,已经开始滲入和影响我们的经济和社会。这意味着政府数字化也必须在技术方案的选择上跟随时代的步伐。

麦肯锡2016年11月发表的一篇关于全球政府数字化的洞见中指出,数字化政府通常始于利用先进的科技重建四个核心能力:

  1. 数字化服务
  2. 自动化工作流程
  3. 基于数据的决策
  4. 通过与企业和个人进行数据共享进行创新

而实现这些核心能力的数字化建设,又需要四大运营和管理引擎来保障,包括:

  1. 具有远见和深度的发展战略
  2. 支持战略实施的组织架构
  3. 领导力/科技人才/组织文化
  4. 先进的技术和开发方法

谈到先进的技术和开发方法,就不得不提到新加坡GovTech下属的GDS(政府数字化开发团队)。这个组织的管理方式很像一家创业公司,各团队努力使用先进的技术、工具、开发实践以及敏捷项目管理方法完成产品的设计和开发。GDS里也有不少实验和原型项目,例如无人机、物联网、3D打印等技术,用于验证创新解决方案。

结语

从SingPass ID一站式访问政府服务,企业注册流程自动化,利用数据分析进行交通管理决策,政府数据共享以及创新验证这些事实中,我们能看出新加坡政府在数字化各项核心能力建设方面都取得了显著的成就。从国家总理,高级官员,到科技项目负责人,均能看到运营管理引擎持续改进的信息动态和行动。在这些核心能力的建设和组织/文化演进过程中,政府也提供给了科技企业和个人大量的机会,让我们对这个国家的数字化未来有更多期待。

新加坡政府的数字化旅程仍然在继续,新的问题和挑战也会不断出现。但其三十年来走过的数字化之路,以及其对政府效率和国家经济提供的价值,值得任何政府和企业深思和学习。


参考信息:

Department of Statistics Singapore :http://www.singstat.gov.sg/

Ease of doing business ranking – The World Bank:http://www.doingbusiness.org/~/media/WBG/DoingBusiness/Documents/Annual-Reports/English/DB17-Full-Report.pdf

Transforming government through digitization – Mckinsey&Company:http://www.mckinsey.com/industries/public-sector/our-insights/transforming-government-through-digitization

Singapore eGov Masterplans:https://www.tech.gov.sg/About-Us/Corporate-Publications/eGov-Masterplan

GovTech’s journey:https://www.tech.gov.sg/About-Us/GovTech-Journey

MoM won an award:https://www.tech.gov.sg/technews/digitalgov/2016/10/winning-gov-innovation

GovTech key values:https://govinsider.asia/innovation/agile-bold-and-collaborative-are-key-govtech-values-ceo/

Prime Minister Lee Hsien Loong’s comments on the progress of the Smart Nation Program:http://www.straitstimes.com/singapore/singapore-can-do-much-more-when-it-comes-to-adopting-new-technology-pm-lee

Singapore Smart Nation Program:https://www.smartnation.sg/about-smart-nation https://cmp.smu.edu.sg/ami/article/20161108/singapore%E2%80%99s-vision-smart-nation

https://www.tech.gov.sg/Media-Room/Media-Releases/2017/03/Formation-of-the-Smart-Nation-and-Digital-Government-Group-in-the-Prime-Ministers-office

Aging problem in Singapore:http://brandinsider.straitstimes.com/hitachi/solutions-for-an-ageing-population/

The 4th industrial revolution:https://www.weforum.org/about/the-fourth-industrial-revolution-by-klaus-schwab

Government Digital Service Team:https://www.techinasia.com/ida-hive-govtech-singapore

Open data:https://www.smartnation.sg/initiatives/Mobility/open-data-and-analytics-for-urban-transportation

Share

绩效考核 – 敏捷转型的鸿沟

关于敏捷转型,有多个层次和角度去规划、实践、观察和推动。本文的关注点是,以小见大,从一个转型中的团队不断走向成熟必然遇到的一道屏障展开,希望能够给转型伊始的管理者一些实质性的建议。

一、敏捷转型过程中的必然挑战

团队级敏捷转型的成熟过程可以参考一些文章,比如ThoughtWorks同事蔡同写的“团队敏捷转型的三个阶段”,其中详细分析了三个不同阶段的关注点和度量指标。另外,ThoughtWorks在对某家全球性银行实施敏捷转型过程中,定制了一个三层的敏捷成熟度模型如下(其他成熟度模型大同小异):

敏捷团队走向成熟的三个阶段

在团队实施敏捷的过程中,虽然可以按照上述文章或者上图大致的路径推进,但还有很多难以避免的问题,却足以成为敏捷难以为继甚至倒退的关键障碍。典型问题是传统管理方式跟敏捷价值观之间的冲突,其表现如下:

  • 经理:敏捷追求的是打造自组织团队和成员能力多样化,那么我如何考核某个员工做的好还是不好?有哪些新的KPI?
  • 经理:是不是可以按照一个员工完成的用户故事点数来考核他的年终绩效?
  • 经理:怎么样才能促进团队成员之间多协作?一个团队成员请假,这部分工作就搁置在那里了,要是能多协作,就可以替补一下。
  • 经理:小李,你看这个任务你来吧,这周五能不能完成?(殊不知,小李心里想的是本周五休假陪老婆过生日)
  • Scrum Master:为什么站会的时候大家都各自更新各自的,没有任何“相互关心”的交流,站会没啥用啊!
  • 团队成员:我在迭代开始已经认领了卡了,我这周快做不完了,为什么要帮他啊?而且我的确不懂他那一块啊!
  • 团队成员:今年的绩效考核我的目标已经定好了,如果达不到我的工资就加不了多少,我还是多关注自己的事情吧。

以上表现,究其本质原因,就是传统的绩效考核方式跟敏捷价值观和原则的冲突。这道文化和价值观的“鸿沟”可能明显表现在团队从Level 1到Level2,或者Level 2到Level3之间,因为Level 2和Level 3其目标的实现都需要依赖于一支为共同目标协力前行的高绩效团队(见下图)。为何这是一道鸿沟?先认识一下传统绩效考核。

传统绩效考核是敏捷转型过程中需要跨越的一道鸿沟

二、传统绩效考核

传统绩效考核的三个目标是:

  1. 提升员工个人的能力
  2. 提升组织产出
  3. 决定涨薪和升职

一般的做法如下:

  1. 每年进行一次年终考核
  2. 年初设定目标,跟部门、团队的目标对齐然后分解
  3. 半年或者一年跟经理考核一次
  4. 最终评级结果决定涨薪和升职情况

举例说明某家企业的绩效考核方式:

目标设定:设定目标的时候会有模板,这个模板自上而下逐层分发到各个部门,员工导入模板后,开始制定目标。目标包含业务目标和跨职能目标两部分。其中跨职能目标,比如安全条例遵守情况;个人学习提升指标,比如组织活动、分享等情况;业务指标,基于业务线以及个人角色来,比如是QA,如何保证产品质量、成功上线等等;

制定目标时间:年初

考核时间:每年两次,年中和年末;首先需要员工写出Self-assessment,然后跟经理review

考核结果:分为4个档次,Top、Strong、Meet和Below

级别最终评定方式:People Manager会跟员工一对一沟通,很少征求其他员工的意见,会寻求来自于其他管理线的反馈,比如业务线经理,项目经理等等。

如何影响涨薪或升职:某个部门每年涨薪预算是确定的,每个团队会分到不同级别的考核结果比例,比如Top占比5%,Strong 10%,Meet70%,Below15%。People Manager根据团队考核结果排名,上报到更高层级排名,从而在有预算的这个层级大排名确定最终涨幅或者是否升职。

三、绩效考核的困境

绩效考核的核心是使用KPI考核结果来对于员工的绩效进行排名,从而奖励(加薪、升职)那些排名靠前的员工,迫使靠后员工努力改进和提升。事实上,也许绩效工资能够起到激励排名靠前的员工,但最大的问题是:绩效工资并不能激励排名靠后的员工做得更好。

20世纪的管理大师爱德华.戴明认为:

绩效考核、绩效排名以及年度考核是管理上七大顽疾之一。

对于以上表述,我采访过几个HR朋友,他们深有同感,绩效考核的理论和框架很好,但在落地时变成了经理的主观判断。而且绩效考核本身并不是达到绩效考核目标的唯一、有效手段。

以上传统的考核方式跟敏捷原则存在很大冲突,对于建立自组织团队以及职责共享的文化起到十分严重的负面效用。

传统绩效考核与敏捷价值观之间的冲突

显而易见,传统绩效考核已经成为敏捷团队走向成熟的掣肘,成为团队在敏捷之路上走得更远的鸿沟。

四、如何破局?

作为咨询顾问,需要解决的是如何调和敏捷价值观以及原则与传统企业的控制型文化之间的冲突,为一线经理们提出一些切实可行的建议从而保证敏捷转型可以深入展开。不得不承认的是,很难在短时间、小范围内对整个组织的绩效考核机制进行彻底变革,这个话题留到本文最后一部分探讨,但并不是没有可以尝试的方式。

首先讨论一下经理们最关心的如何达到绩效考核目标,其本质是要回答如下关键问题:

  1. 如何决定给员工涨多少薪水?
  2. 怎么决定谁应该升职?
  3. 怎么决定谁应该被解雇?
  4. 员工如何能知道他们需要做得更好并努力提升自己?

其实,答案也很简单:

  1. 即使没有严格的绩效考核过程,作为管理者你也能够知道谁做得好,谁做得不好,所以作为管理者,在践行敏捷价值观和原则的同时,照样可以适配传统的绩效考核来得到结论。而且,除了基于绩效的薪酬方式PFP(Pay for Performance),还有其他值得探索的薪酬方式
  2. 升职对于高绩效人员来说未必是最好的激励方式。因为在敏捷环境下更倾向于扁平的管理模式,对于“升职”应该重新定义,创造更适合、更具挑战性的新职位给员工,帮助其发挥才能,从而帮助企业提升响应力,提升团队敏捷成熟度,比如转型过程中的内部教练。而且,在传统的职业通道里面,“升职”往往意味着承担更多的管理职责,一个高绩效员工真的喜欢或者擅长做管理吗?
  3. 其实解雇一名员工,如果真的必须要发生,不需要等到年度考核或者合同到期再做(虽然好多公司还在这样做,我大学一个朋友最近就遇到合同到期被解约的情况)。这样的做法既不经济,也不高效,对双方来说都是失败的方式。遇到绩效不好的员工,首先应该思考的是团队是否给予他及时反馈以及足够的帮助;其次,他是否被安排到了合适的岗位。如果这些问题答案都是肯定的,那么他的工作自然就会被转嫁到其他员工身上。团队应该请求更高层次的职能经理基于事实的反馈,请他另求更合适自己的工作机会。
  4. 真正的高绩效员工,未必是为金钱而工作,最能激励他们的是有挑战性的工作和合理的自主权。通过对于产品价值、质量以及交付效率的度量,透明公开可视化这些指标,更容易激励员工做得更好。以产品本身做的好坏作为激励,更持久和长远。员工在透明的工作环境里面的表现为所有成员一览无余,同僚的压力会激励他前行。相反,如果发现不为这些指标所动,不愿意把产品做得更好,就回到问题3。

敏捷环境下,绩效考核的关键思想转变

所以为了打造高绩效敏捷团队,结合传统公司的管理方式,作为启动,管理者需要把握三个关键“考核”思想的转变

  1. 从考核个人绩效转移为考核团队成效 – 以产品的好坏来评价团队表现;
  2. 从横向比较员工绩效转移为纵向比较个人成长 – 对于个人的成长,企业应该定义清楚每个角色的胜任力模型,从而帮助员工设定自我提升计划,而不进行员工之间的横向比较;
  3. 从长周期考核转移到及时反馈与调整 – 缩短反馈周期有利于及时改进,相互反馈有利于增进成员之间信任和理解。

基于以上原则,结合转型过程中遇到的实际案例,给予管理者可以落地尝试的建议如下:

  1. 管理者要积极转换思维,参与一线工作,贡献到实际项目中去。这与精益中的“Go see”原则一致,在工作一线才能看到最真实的约束,比如可以尝试做Scrum Master,或者学习成为企业内部敏捷教练,以及其他自己擅长的业务角色;
  2. 通过参与一线工作,改变传统方式中与团队站在对立面的尴尬境地,更有利于建立信任;
  3. 通过参与一线工作,更加深入的观察团队成员的表现,从而及时提出反馈和改进意见;
  4. 定期跟员工一对一沟通,明确团队需要的胜任力。作为团队的管理者,应该有足够的经验和能力对于日常工作中的所见给予员工及时鼓励或者提供建设性反馈,在此过程中明确团队需要的胜任力,听取员工心声,及时反馈,指引方向;更重要的是要收集员工对自己的反馈,及时调整自己的行为;
  5. 透明“考核”过程,全员参与。尝试每月开展一次类似于360°反馈的茶话会,团队轮流分享自己在过去一个月的成长与进步、还存在的不足、面临的挑战,开诚布公的分享自己开心的不开心的事情。也许刚开始大家放不开,多尝试几次,每次换一个主持人,选择比较轻松的环境进行,慢慢就会有所收获;这是对大家的持续“考核”,也是对自己的“考核”;
  6. 鼓励建立敏捷文化,身体力行。深入理解敏捷的价值观与原则,避免微管理,尝试针对不同任务对员工赋权;给予团队成员试错空间,持续从成功和失败中学习,坚持分享,不要置身事外;
  7. 引导团队坚持每个迭代回顾。将团队的注意力集中到改进产品上,而不是关注自己的KPI,强调团队的目标是把产品做好;
  8. 可视化所有产品度量指标。关注产品好坏,比如质量,交付价值等,度量端到端指标,比如cycle time,上线后的缺陷数,缺陷修复时间等等,聚焦团队目标;
  9. 可视化团队成员贡献。比如建立团队成员学习与分享的物理看板,从而形成正向激励,记录每个人的贡献,建立职责共享文化,自己也要积极参与;
  10. 积极与自己的领导明确敏捷价值观和原则,积极争取自主权,影响其他管理者。

如果能够坚持做到以上各条,利用以上渠道获得的团队信任和事实依据,传统的绩效考核结果也会得到团队的认可。

正如《管理3.0》所说,所有变革最后的失败都是管理的问题。对于转型中的组织,特别是一线管理人员,应该把绩效考核这种管理手段当成“敏捷铁三角”中的一角来对待,那就是调整约束。把它当成跟时间、成本、资源等类似的约束因子来统一管理。一家企业之所以存在,有其独有的文化和运作规则,只有调和好约束,才能最大化敏捷的价值,如下图所示。

管理者应该将“传统绩效考核”视为敏捷项目管理中需要调和的约束条件之一

清华大学管理学教授宁向东一针见血地指出,管理,其本质就是关于如何“破局”的智慧。所谓“局”就是管理者周围的各种资源相互联系,相互作用的一种状态。以上约束,也是软件工程表现出来的组织复杂性,也是一种局。

最后,绩效考核的未来有不少探索者认为是没有绩效考核。2017德勤全球人力资本趋势报告指出:

过去五年,新型绩效管理实践成效显著:在重新设计绩效管理的企业中,有90%的企业在员工敬业度方面有直接改进,96%的企业反馈其流程更加简化,而83%的企业称其员工和经理之间的沟通质量有所提升。

绩效考核领域正在飞速改变,让我们拭目以待!


更多精彩内容,请关注微信公众号:软件乌托邦

Share

精益企业原则之:以产品为中心,而非交付项目

如果要创造一个软件产品,我们现在是怎么做的?

很可能你会先组织进行可行性研究,包括分析市场环境,在纸上算算未来可能的成本和收益。如果技术上也可行,那么就写一份漂亮的商业计划书,编织出美好的数据来说服管理层和财务部门拿到一大笔预算,成立项目。项目启动后首先将需求详细写出来,在正式动工开发之前可能就已经过去了几个月甚至更久。之后负责方案设计的业务分析人员将详细方案文档交给公司的软件开发部门或外部供应商来实现,最后开发团队将软件包交接给一个专门的运维部门部署维护,并提供用户支持。

这就是现在在大多数企业的做法。不仅仅流程冗长,组织结构往往也是按业务,开发,和运维划分成不同的职能机构,大大拉长了一个想法从提出到交给用户的周期,常常错过投入市场的最佳时机;现实中业务人员对于用户到底需要什么、喜欢什么经常产生误判,在这种模式下提前数月制定的大计划就会导致大量浪费;以范围、成本和进度为中心的交付管理使得所有人都迷失了,似乎项目交付就是目的,而忽视了投资本身的初衷是要达到的用户和业务目标,更谈不上持续创新。图Figure 1 展示了这样一种传统结构:

01

Figure 1 阶段化的项目模式

这种项目化的传统模式带来的问题不仅于此。由于开发阶段和维护阶段往往由不同的职能部门负责,在成本上也是分开计算,开发人员往往不会很认真考虑运维因素,可能给系统增加不必要的复杂性,例如引入过度异构的设计或难以理解的数据结构,这导致运维成本增高,然而这些问题却反映到不到设计和开发阶段,组织很难看到围绕一个产品实际产生的所有成本;当生产环境出现问题,只有运维人员苦命地24小时待命,找到快速恢复的办法,而开发人员却可以心安理得地留下系统低质量和不稳定的风险。

以产品为中心的模式

现代科技企业所面对的竞争环境越加激烈,用户和市场的变化迅速,要能够快速适应变化,真正创造用户喜爱的,有竞争力的产品,并持续创新,需要告别以往多年以项目为中心的管理,建立一种以产品为中心的软件交付模式。也就是说,组织的投资决策与治理结构要支持团队解决问题,而不是交付项目,这是建立高适应力、持续创新的精益企业的核心原则之一。组织创造产品的目的就是要解决用户或组织自身(也就是内部用户)所面临的问题,因此以产品为中心,也就是以解决问题为中心;而相反,以项目为中心的则是以计划、预算和职能为中心。

那么要以产品为中心,组织需要在哪些方面做出改变呢?

首先,以产品为中心,要求管理的核心要素从项目的范围、时间和成本转向给用户带来的实际价值和质量。现在很多软件项目的管理者都有类似PMP这样的认证,对如何在范围、时间和成本这三个因素之间周旋很有经验。甚至一些项目管理者几乎全部的工作就是计算各种PV,EV,SPI,CPI值,通过加人减人、加班等方式来保持项目在计划和预算之内,却忽略了最最重要的事情:团队忙于添加的特性到底有没有价值?解不解决问题?

价值是产品的最核心要素,然而这在传统的项目管理指南中基本看不到对它的关注。由于人的本能,那些提出需求的人(如用户或业务部门)往往提出来的是他们认为的解决方案,而交付团队可能连真正要解决用户什么问题都没搞清楚,只将其视为需要完成的一项任务。管理工作围绕价值开展就需要管理者将最多的关注放到对用户的分析和对工作的优先级排序。

具体的方法包括与用户和各种干系人一起确立明确的愿景,对目标用户群进行识别和特征分析,找到评判一个想法优先级高低的标准,设计可以验证假设的实验;在交付过程中管理好团队的在制品数量,确保集中精力将最高优先级的特性快速交付并获得真实的反馈,从而更好地决策产品方向。

正因为围绕价值进行管理至关重要,在以产品为中心的组织中更加强调产品经理的角色,而非项目经理。产品经理或产品负责人是一个团队实际的决策者,决定产品的方向和策略,对价值负责。即便仍存在项目经理,也只能是一个辅助性角色。

另一方面,虽然每个人都口口声声质量很重要,但时间、范围和成本往往都在前期的承诺中被固定了,对任何一项预先计划进行调整都需要复杂流程,而且会被视为管理者工作做得不好。当管理者努力要保障一切按计划行事,那么很自然质量这个隐性因素就成为二等公民被牺牲了,团队加班加点,或临时增加人手,降低上线质量标准。而且软件有其特征,很多质量问题是无法通过功能验收测试来发现的,设计和代码的恶化很隐性。要以质量为核心,就需要管理者在团队内建立普遍的质量意识,提升团队的工程实践能力,提升自动化水平,形成持续改进的团队文化,而不仅仅是完成功能。

范围、时间和成本的管理并非不重要,但在以产品为中心的管理模式下这些因素只是我们交付产品的制约因素,相对于更重要的价值和质量,这些制约因素需要不同的处理方式。如图 Figure 2。

02

 Figure 2 价值、质量与约束

第二,组织要形成围绕产品,也就是围绕业务的组织结构。传统按职能划分的组织导致了不同职能不一致的目标,比如业务部门以市场效益为目标,而IT交付部门则以交付产能为目标,却忽略业务价值,运维部门以系统稳定性为目标,而阻碍快速频繁变更。我们需要打破这种职能化的筒仓式结构,建立由业务、设计、开发和运维等多种技能人员共同构成的跨学科跨职能团队,最好能够同一地点办公,紧密协作。为用户交付高价值、高质量的产品应该是所有成员共同的目标,基于共识来驱动所有人的工作步调一致。如图 Figture 3:

03

Figure 3 产品化的组织结构

有些较为成熟的组织建立了一种矩阵式的结构,即既有以职能为中心的纵向部门,也有以产品为目标的横向组织,但总得来说还是职能为实,产品为虚,员工的绩效考评掌握在职能部门领导手中。常常能看到职能部门在各产品间随意调动人员配置,破坏了产品团队的稳定性、凝聚力和业务知识积累;而且这种强矩阵式结构大大增加了组织的管理消耗,容易导致企业走向一种管理导向文化。而有适应力和持续创新的精益企业更需要一种技术导向的文化(或有些称为工程师文化)。在以产品为中心的组织中产品维度的管理应当为实,而职能方向更像是一种社区,以技能分享和发展,人员培养为主要目的。

在以上组织结构的调整中,最重要的一点就是要让协作的跨职能团队具有一致的目标,以相同的标准来衡量工作表现。不能是以各个职能各自的产出来衡量,比如以需求说明书书写的质量来衡量业务分析人员表现,以完成的需求量来衡量开发人员表现,以发现的缺陷数来衡量测试人员。而应当以产品团队整体交付的价值和质量来衡量,比如用户满意度,用户问题数,业务目标达成等,整个团队责任共担。

运维在很多企业都是一个集中式的部门,负责所有IT系统的运行,很多人对运维工作的印象就是繁琐而无趣,大量人工操作,复杂的发布流程。然而随着技术进步,这些都在发生变化,可以通过自动化的部署,监控和基础设施配置以及采纳云计算来大大降低运维难度,使得产品团队可以自助地完成大多数运维工作,将传统集中式的运维人员解放出来,专注于建设数据中心和自动化运维平台,比如组织级的IaaS/PaaS平台。

第三,应以产品的实际用户和业务成效来衡量进展和表现,而不能基于计划和预算的达成情况来衡量。计划只是一种预测,在不确定和追求创新的场景下计划随时都会改变;预算支出也不能说明我们在达成愿景的道路上已经取得了多少进展。用户成效是指产品确实解决了用户的问题,被用户所认可和喜爱;而业务指标是指产品在商业上取得了成功,为组织带来了预期的收益,这些指标才是我们对产品进行投资的目的,也只能以这些指标来衡量团队工作的进展。换句话说,如果团队在既定的成本内完成了计划的所有工作,然而上线的产品没有人愿意使用,等于没有任何进展,完全浪费。

这里以成效而非产出进行衡量是关键,有悖于一些人的认识。比如输出的文档,书写的代码行,交付的故事点数这些都是产出,产出量再高,如果没有用户、不解决问题则只会无谓地增加系统复杂度,提高运行和维护成本,有百害而无一利。如果所有人的工作都围绕能给用户带来最大价值的特性,以最短的周期发布出去,其带来的成效会远远大于一味地堆砌需求。只有所有成员(不仅仅是业务人员)都理解如何衡量成效,并以此进行考核,才能最大限度地激励每个人去思考最佳方案,而不仅仅是完成任务;而且以产品的成效衡量可以激励团队尽早和频繁地交付,尽早兑现价值。

要能够以成效来衡量进展,就需要我们在提出任何解决方案的同时也要明确如何来衡量该方案的实际价值。典型的例子比如互联网企业常用的用户活跃度,点击率,转化率,推荐率,以及在线反馈等;对业务系统也可以采用像日均处理量,处理成功率,处理周期,业务替代率,以及成本节省等指标。我们随时要牢记于心,任何方案在没有得到真实用户反馈之前都只是一个有待验证的假说。在新方案上线之前,我们还需要采用像A/B测试,金丝雀发布,特性开关等技术手段在安全受控的范围内收集线上运营数据,通过数据来验证假说,以数据为依据进行决策才是科学的,才能避免在决策过程中掺入过多职权或政治因素。

决策不仅仅关乎投资,也关乎停止投资。在有了数据为参考时,如果数据证明产品并不能达到预期的成效,团队可以随时停止在某个产品上的投入,转向其它更有价值的工作。而项目化模式下,往往都会执行到预期计划的项目结束时间点。

第四,以产品为中心意味着团队要对产品的全生命周期负责,而不是只对某一个项目阶段负责。既然各种技能人员都有了共同的目标,那么开发、运维等成员就需要尽早参与到需求分析与方案设计过程中,而不是仅仅接受前面阶段的产出;业务分析和设计人员也需要关心开发、运维的每个环节,确保自己的设计被正确地实现,并且第一时间收集到用户的反馈。每个人从自己的技能角度进行分析,提前发现问题和风险,产生尽可能最佳最简的方案,减少浪费,并跟进自己的工作产生的后续影响。

产品运营的工作直接和用户打交道,通过线上和线下的方式培养用户群,倾听用户反馈。但不少企业的运营由单独的运营部门执行,用户声音不能立刻传递给产品的设计人员,最多采用日报、周报的方式提供报表,而且这些报表里的数据既不聚焦,也不直观可视化。因此产品的业务和设计人员应该全生命周期负责,既要融入整个交付过程,也需要直接领导或参与运营工作,每天直接接触用户,才有可能产生移情,站在用户的角度对产品进行持续改善。

另一方面,团队成员要直接对产品的运维负责。由产品团队自主决策是否可以发布,并通过自助方式将新版本发布上线。然后团队需要随时解决线上出现的问题,比如分析师、架构师和开发人员采取轮流值守,一旦生产环境出现问题必须立刻响应,谁写的代码谁维护,保障系统运行的稳定性。这样的职责体系使得分析人员避免添加一些价值不高,甚至带来用户困扰的功能,提升用户体验;开发人员在写代码时会考虑是否带来运维问题,努力提高质量,主动简化系统,毕竟谁也不愿意周末因为一通电话跑到公司去解决紧急问题。

全生命周期负责的模式下,对团队成员的能力成长也更有利。每个人根据自己的兴趣和擅长可以较容易地接触到不同类型的工作,发掘自己潜力。这种模式下组织需要更多的T型人才,即在某一方面专精的同时也能承担多种职能的工作。越是在高不确定环境下工作的团队,越是创新的团队就越需要这种多技能的T型人才。(参考:http://wiki.mbalib.com/zh-tw/T型人才)

第五,建立一种以产品,或者说业务活动为中心的成本核算体系。在项目模式下,可能业务分析阶段的投入计入市场、业务部门的成本;开发团队的支出计入开发项目成本,可能是企业的资产或费用;而运维由于集中管理,往往一个人员同时支持很多产品,其成本很难对应到产品,只能通通计入运维成本,往往计入企业的运营费用。在这种模式下,很难看清楚围绕某个业务机会究竟付出了多少成本。

在以产品为中心的模式下,要将所有的成本尽可能归属到具体的产品,也就是业务活动。如果已经建立了跨职能的产品团队,并且对全生命周期负责,我们就能很容易地通过计算这个产品团队的成本来得到组织在某项业务上的投入。甚至各种公共资源的投入,比如数据中心一类的基础设施,也可以通过计算资源占用量等手段将其成本分配到各个业务产品。从而,产品团队的领导者和组织管理层就能够更加清晰地看到各项业务活动与成本的直接关系,看到真实的投资收益,从而更加科学地做出投资决策。

这种成本会计法就是80年代库伯和卡普兰教授所提出的“作业成本会计”方法(Activity Based Costing,参考:https://en.wikipedia.org/wiki/Activity-based_costing),其被证明是一种能够在不确定环境下支持创新的成本核算体系。然而尽管提出很多年,真正将其运用到实际的企业并不多,根本原因就在于大多数企业的职能划分过细,很难将业务活动的支出从各个细化分工的职能中合理地识别出来。要运用到IT行业的软件产品开发,就需要组织找到一种方法将市场、产品、开发、运维各环节的支出按业务活动区分开来,可能需要一些会计工具的支持。

最后,产品团队需要有足够的自主权力,根据实际的用户喜好和市场环境快速做出决策。在美国空军上将博伊德谈论关于在不确定环境下竞争的决策机制时(参考:https://en.wikipedia.org/wiki/OODA_loop),他强调“隐式指引”胜过“显式指引”。在企业里,“显式指引”就是所有的决策都由集中的决策机构自上而下以正式指令或遵循流程的方式来下达,而“隐式指引”则是身处竞争中的产品或业务团队根据事先明确的目标和当时的环境条件自主做出决策,而没有来自中央的正式指令。只要产品团队具备适当的能力,尤其是以用户为中心进行设计和进行安全的实验的能力,完全有可能找到比中央集中决策更加优化的解决方案,并且决策速度要快很多。

相反,在项目化的模式下,当面对突发的情况和环境变化时冗长的流程和分散的职能让进行实验和获得反馈的周期更长,会让决策束手束脚,进而错过机会。

具体来说,产品团队所需要的自主权力包括:

  • 选用人的自主性,产品负责人能够雇佣具有必要胜任力并能融入协作的人
  • 出资决策的自主性,在一定的范围内,要为新发现的机会能够随时获得额外的预算,或停止投资,而不需要集中式的财务审批
  • 决定做什么不做什么的权力,在几个月之前作出的大的计划往往在团队获得更新的信息时,原来计划的范围或方案需要作出调整,这样的调整可以随时进行,不需要流程
  • 决定何时发布产品或特性的权力,团队可以频繁地随时自主策略将实验或特性发布给用户,这样的实验发布不需要冗长的审批流程

在越是追求创新和适应力的企业里,这样的权力下放会做得越彻底。像Netflix,Etsy这样的企业甚至开发人员都可以自己决定随时将代码变更推向生产环境。

在这个过程中,上层组织需要做的就是保证产品的所有决策符合组织的战略,与组织所要实现的目的和愿景是一致的,确保存在一种机制使得团队在决策出现错误时也是安全的,并在产品团队自身无法获得足够信息做出有有效决策时提供协助。

讨论团队自主性,除了治理结构上提供的授权外,不得不提到另一个限制因素,那就是系统架构。如果产品与产品之间,产品内的各个业务领域之间架构上耦合过高,我们就不得不在各团队之上建立一层额外的机构来协调彼此的进展,就必然会限制产品团队各方面的自主性。要消除这一层剥夺自主性的额外集中控制,就要求整个企业在软件产品的架构设计上合理地围绕业务建立系统,并在应用、数据和环境层面做到高度松耦合(关于系统架构与组织结构的关系更多论述参考“康威定律”,https://en.wikipedia.org/wiki/Conway’s_law)。要做到这一点,正确的SOA和微服务架构模式是需要考虑的策略。

总结下来,以产品为中心具体体现在以下六个方面:

04

Figure 4 以产品为中心的六个方面

产品化模式的根本目的是要“最大化产品价值”。这里所指的价值体现在真正解决用户的问题,提供优秀的用户体验,并为企业带来持续客观的收益。

无论你的产品还处在需要通过实验来验证商业模式的阶段,还是需要通过丰富有价值的特性来规模化的阶段,都需要多种学科多种职能的人在高度一致的目标下紧密协作,让实验和特性能够持续频繁的交付并立即得到用户反馈。若真实的价值与预期不符,就立即做出调整,甚至放弃投资。这一目标的达成只有在组织的投资决策与治理结构以产品为中心的模式下才能做到最大化。

以上所描述的产品化模式不仅仅适用于为外部用户/客户提供的产品,也应当用于内部IT系统的开发。以往大量的内部IT系统都依靠长周期大笔的投资,并通过行政命令推行,这是造成这些系统普遍不受欢迎、不易用,却成本极高的根本原因。只有同样采用围绕业务、围绕产品为中心,通过实际的用户成效为衡量标准,提供给内部用户可选择使用或不用的权力,才有可能改变内部IT系统各种被人诟病的问题,最大化IT系统给组织带来的真实收益。

Share

大象转身,一蹶不振还是华丽重生?

以社交媒体、移动、客户数据洞察、物联网(Internet of Things)为代表的数字技术正在革新商业生态圈。数字化风暴极速冲击着金融行业,第三方支付、P2P网贷、众筹融资、电商小贷、虚拟货币、金融网销、垂直金融搜索入口、理财工具和服务、金融咨询和法务援助等等创新金融模式,极大地颠覆着金融生态。来自花旗银行的报告称 ,以金融科技驱动的这些新型金融业务已经把传统金融业务逼上了绝路,以美国市场为例,到2023年,新型金融科技的收入将占到17%;在中国,当前支付宝的支付量已经超过了工商银行和招商银行信用卡交易量的总和。将对于传统金融企业来说,数字化转型、投资金融科技是必然、唯一的选择。

数字化转型是传统金融企业的共识,但转型路线却不同,大致呈现出三种模式:

  1. 在组织外部设立单独运营实体。运用资本优势和资源优势,通过战略投资,开发新的目标客群或细分客群,以全新「互联网商业模式」运营。新旧模式并行不悖,两条腿走路。典型的案例如「众安在线」之于平安。
  2. 在组织内部建立「数字特区」。企业内部对子公司或部门充分授权,允许各自创新经营模式和方法,相互竞争,倒逼整个企业走向「数字化」。这好比平安集团下的陆金所之于平安银行。
  3. 全面转型,让所有流程、产品与服务立即实现数字化。立足既有商业模式和业务运营优势,建立数字化渠道、提升数字化能力,在组织结构、企业文化、数字化技术、产品创新、运营模式做全面转型,成为全面「数字化」企业。

通常认为,全面转型最难,会遭遇到组织文化、业务运营、产品和技术等多方面的冲突和挑战,如同大象转身,或一蹶不振,或华丽重生。过去十年间,我们有幸见证了一家国外某传统大型金融企业的转型历程。他们有着怎样的经历?有什么样的经验和教训?同为大型传统企业,我们可以从中学到什么?

转型企业背景

该企业是某国家最大金融保险集团,转型之前兼并购买了众多市场竞争者,总资产约1000亿美元,业务涉及银行、保险、制造维修等领域,旗下拥有银行、一般保险、寿险等业务线和20多个市场品牌。

转型前的2006年,企业面临前所未有的挑战:

  • 组织机构庞杂,业务冗余,效率低下。因为兼并购买了多个市场竞争者,造成组织结构过于庞杂、文化不统一、业务冗余、运营成本持续攀升。如同老爷车,干着急就是挪不动。
  • 市场竞争白热化,第一的位置受到威胁。身处开放性的金融市场,有来自海外的竞争者和本土的跨界竞争者,过分依赖少量客户,业务上保险强银行弱,而排在第2、第3的竞争对手有很强的银行业务能力,导致第一的地位岌岌可危。作为上市公司,兼并购买其他小型保险竞争者也是无奈之举。
  • 产品创新乏力,缺乏新的业务增长点;传统行业的思维和开发方式无法适应市场变化。
  • 人员成长遇到瓶颈,复杂的组织结构、管理模式导致人才流失严重,企业缺乏活力。

企业遭遇发展瓶颈,必须转型,怎么办?

数字技术的兴起对于当时这只大象,与其说是「风暴」,不如说成了「救命稻草」。相对于互联网金融企业,该传统金融企业也具有它自己的优势:占据行业领头位置,熟悉行业规则;过去多年运作积累的风控能力和技术能力;相对庞大的存量客户资源;多年积累的业务运作能力;专业的人才储备和社会公信力。另外,还有锐意进取的领导层和协作型的企业文化。

挑战和问题集中到三个方面:如何打造数字化基础架构和能力?如何与客户建立起紧密联系?如何提供个性化、差异化的体验和服务?从集团CEO到业务CEO到CIO,共同构建了围绕这三个核心问题的转型愿景:

emagazine pics-05

图1. 企业转型愿景

愿景只是美好的表象,执行落地才是硬道理。愿景需要转化为具体的执行战略。该企业做了如下跨度超过十年的的转型路线图:

emagazine pics-07

图2. 企业转型战略

该企业开始了为期十年的改革和持续改进,每一个阶段重点解决一个问题:

  • 第一阶段:聚焦于敏捷组织转型改革企业组织结构和文化,为组织赋能。企业最重要的活力源泉在于人才,传统臃肿的组织结构和文化严重地束缚了人才的活力,所以率先要先改革组织结构和文化,恢复组织机能;
  • 第二阶段:聚焦于IT系统和业务流程简化,释放组织潜能,向「客户」为中心转移;
  • 第三阶段:聚焦于技术战略,构建多元化数字渠道,提升用户体验。

艰难而漫长的转型历程

第1阶段:敏捷组织转型 2006-2011

企业做转型,组织文化必须先行,该企业的领导深谙其道。转型战略的第一步,即从敏捷组织转型开始。通过与全球顶尖的敏捷组织转型厂商合作,该组织实行了如下举措:

  • 运营合一化。所有业务不管原来归属于哪个公司,统一按照业务线重组,每一条业务线的不同品牌的产品采用同一套管理团队和管理制度;
  • 组织统一化。原有不同公司的IT部门、客服部门等全部合并重组,成为统一的IT服务组织、客户服务组织等;
  • 企业同一化。整个企业,不管历史上归属于哪个品牌哪个公司,全部同一战略,同一文化,同一步调。
  • 进行组织改革,实施「敏捷组织转型」。先从IT部门开始,引入全球顶尖的合作伙伴,全面进行敏捷转型,贯彻敏捷文化、管理实践和工程实践;然后再由IT部门,扩展到业务部门,打造「以人为中心」、协同的工作文化,同时提升个体的适应变化的能力。

在这五年的敏捷组织转型过程中,80%的员工接受了敏捷培训、每一个业务、IT团队都能够运营敏捷实践来提升响应市场变化的速度。更让领导层没有想到的是,此项变革不仅让组织产生活力,而且直接因为消除浪费而降低了运营成本:据集团年报数据,因为敏捷组织转型每年结余2亿左右。这坚定了领导层战略转型的信心。

第2阶段:遗留系统优化 2011-2014

很多传统金融企业在转型时,往往会从「客户端」出发,比如先做移动应用寻求产品销售、利用社交媒体做数字化营销。该企业在这一阶段内部也形成了很大分歧。中间也是一波三折。最终,强有力的领导层决定从企业「中端」和「后端」开始,先进行IT系统和业务流程简化,在此基础上再加大消费者端的数字化。

  • 简化后台系统。启动持续3年大型后台系统简化项目集,比如其中的一个核心业务系统14个后台系统简化到1个;整合组织内部运营系统,如财务、人事、客户关系系统(CRM)、核心精算系统、计费系统,以简化流程、减少浪费。
  • 统一数字渠道。
    • 整合所有业务和客户数据。所有业务和客户数据迁移到统一整合的数据存储后台,清理了重复数据,也可以准确鉴别客户信息,实时获取客户购买集团下所有产品,为进一步使能数据能力打下基础。
    • 统一业务流程。在统一数据和业务交易平台的基础上,统一所有品牌的销售、风控、和服务流程,同一呼叫中心的服务可以在多品牌中复用(比如客户修改地址,多个产品的地址可以同时修改好)。这样,每一次合并一个品牌到统一流程里,就会同时关掉原有品牌下的若干呼叫中心,极大地节省了成本,提升了运营效率。
    • 整合业务数字化渠道,统一构建核心在线平台。不追求在线平台中产品和功能的丰富性,而是让20多个不同品牌能用同一在线平台,然后逐步丰富产品线和功能。

后来在回顾这段历程时,我们才意识先从「中端和后端」开始加强数字化是明智的:如果客户数据都不统一、后台流程落后冗余复杂的情况下,精准数字化营销、在线体验是不可能提升的。这一阶段的转型,据企业年报中的数据,我们看到给企业带来的转变是:

  • 转型第1年收益4百万美元;
  • 每年IT成本节约2.2亿美元;
  • 产品上线周期减少了40%;
  • 综合线上营收占比提升到了75%;
  • 单个线上用户价值提升了3倍;
  • 线上渠道销售转换率提升了5倍。

第3阶段:数字渠道差异化 2014-2016

有了组织文化做基础,统一的IT系统和业务流程做保障,接下来的这个阶段,就是革新技术战略,构建多元化数字渠道,提升用户体验,向真正「互联网化」的转型愿景迈进。

emagazine pics-06

图3. 全渠道经营模式

emagazine pics-08

图4. 差异化和个性化业务服务

  • 革新技术战略: 与最领先的云厂商合作,承担行业领军地位,推动建立金融行业云架构行业监管和规范;进一步提升IT运营能力,跟踪用户线上行为足迹,在更精准的时机接触客户,提高转化率;
  • 多元化数字渠道建设,保险业务线上线下业务完全整合,形成「全渠道」经营模式。线上线下的整合其实更是一场组织变革。企业的领导层决心非常强,就是要「弱化渠道」,改革业务组织结构和绩效考核方式,按业务线来综合线上线下业绩综合考核。每个业务线的品牌迁移到新的在线平台中,就会关停原有品牌的若干电话呼叫中心,这在项目启动之始就会纳入计划,保证执行。
  • 个性化用户体验,差异化业务服务。以用户数据分析为基础,找出目标用户群,进行用户访谈,验证需求,通过体验设计来推出创新产品已经成为大家可以相对熟练应用的工作模式。在线上跟踪用户行为数据,提供基于位置或是相似度的商品、服务网点、理赔中心推荐,提供以用户为中心的自主服务为增强客户粘性,在枯燥的用户投资管理中,加入游戏化成分等。

这一段历程相对于前两个阶段,要顺利一些,因为经过多年的敏捷组织转型、精益创业和体验设计的思维已经深化到组织基因中。虽然这个阶段目标还未达成,但对比十年前企业转型前的状态,企业无疑更加在线化、数据化:

  • 从政治复杂、效率低下、自主能动性差,变革为拥抱变化、拥抱创新的组织;
  • 从陈旧落后、不可用、 风险性高的IT环境,变革为以自主云平台为基础的安全弹性的IT环境;
  • 从复杂、低效、落后的IT系统,到简化易用统一的技术平台;
  • 从破碎、分散的数据碎片,到整合智能的大数据分析支撑;
  • 从标准化、单一化的业务服务,到个性化、差异化的服务;
  • 从单触点与用户孤立连接,到多触点与用户紧密连接。

「大象转身」的启示

从2006到2016,可谓「十年磨一剑」,而且转型的路途仍在继续甚至步调更快。但欣喜的是,它给业界提供了「大象也能转身」的参考案例。每一个大象都是不同的,转型之路也必然不同。如果说有启示,借用该企业CIO的话,即:

  • 企业全面转型必须系统的战略规划,而不是在单点上应用技术就能奏效;
  • 转型需要坚定的领导力和执行力,十年如一日,保持战略的连贯性和执行力度;
  • 组织结构和文化是企业释放潜能的本源,变革必须以敏捷组织转型为基石;
  • 全球顶尖合作厂商能力注入,是激发企业活力、刺激企业变革的关键举措;
  • 「技术即业务」,要做技术的先驱者,主动变身成技术公司,以技术推进业务创新。
Share