前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >不要让预算出资成为创新的绊脚石|商业洞见

不要让预算出资成为创新的绊脚石|商业洞见

作者头像
ThoughtWorks
发布2018-04-17 18:03:33
4900
发布2018-04-17 18:03:33
举报
文章被收录于专栏:ThoughtWorksThoughtWorks

姚安峰

ThoughtWorks

先讲两个故事。

2014年。

和某客户IT团队讨论如何对产品进行滚动规划,团队非常认同应当根据每次发布后的用户反馈来调整计划,我们详细辅导了相关方法。然而实行半年后团队抱怨这种持续规划意义不大,因为规划中能够调整的仅仅是一些小的优化工作,而对于主体业务需求,即便用户反馈对自己用处不大,团队依然不得不继续做下去,因为这是年度目标里已经提出来,给领导汇报了的。

另一件故事则发生在最近。

我们帮一个小客户解决基于GoCD做持续集成中面临的技术问题,在辅导中我们让客户意识到,“GoCD不仅仅是基本的开源CI工具,更可以端到端的实现从代码提交到生产发布的整个流水线的自动化,实现持续交付。”

团队负责人认可这样的自动化流水线,认为这对提升整体效率和协作非常有意义,可以解决现在面临的很多痛点。然而当把这个诉求提交到上层领导时,被告知今年的预算里没有计划这方面的投入,需要放到明年的预算中……要知道当时才刚进入5月,距离明年还要过8个月,团队负责人非常沮丧。

1

传统的集中式年度预算

在当今这个社会和技术飞速发展的时代,一个组织要进行产品创新或过程改进面临着很多不确定性。新的想法、市场新的趋势以及组织需要尝试更好的工作方法、工具,这些机会随时都可能浮现出来,你无法预先准确知道。

然而一个组织的目标和投资(如分配给某个产品一年的预算)若按年进行规划,那我们谈论的"敏捷"、“精益”,要想进行实验并根据实验反馈来持续设计产品的理念就无法产生其应有的效果,只能在一些细节上微调。

很多传统企业采用的是年度预算制度,由高度集中的部门来审核和批准各个层级部门的预算,这份预算里包含了对一年目标的设定:一年能够花多少钱、要怎么花、花到哪儿等。中央的预算管理部门核心目标是“驱动组织各个层级都有正确清晰的目标,准确地管好花好每一分钱。”然而却忽略了一件事:组织所能掌握的信息是有限的,预测失误会时有发生,一旦外部环境发生了变化,组织能够多快地改变原有目标和出资?

各个部门因为一年只有一次主要的机会获得预算,而资源总是有限,不可避免的都想方设法堆砌很多理由,编制数据,相互竞争尽可能拿到多的预算。即便拿到的预算超过了实际需要,每个部门也总会想方设法将它花完,不然明年的预算就可能减少。

这种集中式的年度预算制度虽然在过去几十年来证明是一种成功的治理机制,促成了很多企业的成功。然而在今天,尤其是在创新研发领域,在面对激烈的市场竞争,需要持续创新的场景下,这样的制度越来越开始制约着组织的适应力、响应力,造成非常大的浪费,很不"精益"。

2

将预算出资与财政年度分离

这种机制主要的问题在于它将"设定目标"、“预测”和“资源分配”几件事情揉合到了一起。要建立更有适应力的预算制度,首先就是要分离这三个关注点,将预算出资与财政年度分离,如下图示:

设定目标

有些企业管理者将团队承诺的工作内容当做目标,比如年度目标是:

"要建立一站式的智能化数字运营平台" "要完成12个省份的门店系统推广" "要完成80%产品的看板实施"

这样的年度指标并不是从组织发展的真正目的和关键绩效角度进行衡量的,而只是个别人认为可以达成某个真实目的的解决方案;相反它锁定了组织达成真实目的可选择的解决方案,忽略了不确定性,形成一种强控制文化。如果中途发现这样的解决方案并不是最有效的途径,通常也会继续做下去,因为是否完成该任务决定了个人的年终绩效。

目标应当根据组织真正的目的和关键业绩来衡量,比如上面的例子可能想要达成的真实目的是:

"提高投资回报率" "扩大用户量" "缩短IT交付周期,提升对市场的响应速度"

进一步要衡量组织是否在达成这些目标的道路上取得了进展可以设置量化的指标,并选择合理的度量手段,例如:

"单用户收益提升15%" "用户量提升30%" "平均交付周期(TTM)降低30%"

组织的目的是相对恒定的,而达成目的的解决方案可能有多种,衡量指标并非一成不变,各业务、产品或职能团队应当有足够的自主性通过实验来找到最有效的方案,必要时可以和上一级协商调整目标,只要能有利于更好地实现最终目的。

更重要的是,不能将指标达成作为绩效考核的依据,一旦度量成为影响薪资和晋升的考核指标,将激励人们为了达成短期指标而牺牲掉长期利益,甚至数据造假。切记一句名言"你度量什么就会得到什么",唯一破解度量悖论的解药就是将度量指标和绩效剥离。

滚动预测

预测是传统预算制度中要做的第二件事,中央的预算管理部门根据每个部门提交的计划工作内容、预期收益以及清单中每个工作项预计需要的成本统计来决定是否分配资源,分配多少。如果我们所处市场环境是完全可预测、缺乏竞争的,这种方式可以让经营者进行更高效的管理;然而这个条件在现代商业环境中越来越不现实,年度预测带来的更多只是假象了。而且要在年初编制出这种对工作内容及成本收益的预测总是让人伤透脑筋。

“预测”这项工作本身不会给用户和客户创造任何价值,从精益的角度来讲,在这上面花太多时间就是"浪费"!组织各层级要充分接受“未来难以预测”这一信条,努力摒弃掉用来做不切实际预测的大把时间,更不应遵照一份僵化的计划来开展工作,而是致力于将时间真正投入到为用户和客户创造价值的工作上。

那预测还要做吗?从提供可预见性和识别管理风险的角度,预测对于内部管理和外部投资者有一定帮助。但要减少浪费、提高组织适应力,预测的周期就必须缩短,而频率要提高。

有一种已被很多企业验证的有效方式是"滚动预测"。将对未来的预测分成几个周期,每个周期都较短,比如一周或一个月。当前近在眼前的预测周期确定性高,可以较详细地列出,而对越远的周期进行的预测就越模糊。当每一个预测周期要结束时,就在最远的周期之外追加一个相对模糊的周期目标和预测,这个活动应基于现有信息快速完成,不必追求高准确性。而且整个由近及远的预测数据会根据最新获得的信息持续调整。不确定性越高,要求适应力越高的环境下,这样的周期就越短;在极致的探索性工作中甚至没必要做任何预测。

比如在软件研发过程中我们推荐进行三个版本的滚动规划,可以采用类似“用户故事地图”这样的方法。版本周期根据产品特征而定,通常不超过1个月,只有最近一个版本团队需要确定每个工作项都已进行了清晰的定义,确定其工作量估算,确定团队可承诺的交付范围;而后一个版本只是暂列出已知可能要做的工作,也许还没有定义清楚,以识别和管理风险、展现产品演进方向为目的;再之后的第三个版本基本不做具体工作的计划,只是粗略地列出可能的机会,模糊的目标。

3

动态资源分配

最后,当目标设定对齐了组织目的,指标变得可变,不再做年度预测,那么基于预测的资源分配自然也不再是按年来审批。如果团队发现了新的机会想要开展一项原来规划中没有列出的项目,不得不提交一份详尽的报告,走一个冗长的流程来获得领导认可和预算部门的审批,结果可能要么团队会放弃,要么资源审批下来机会却已错失,要么申请被流程否决;这对于创新和实验是一种严重伤害,自然而然就产生了官僚型的文化。

资源的分配应当变得动态,在需要时就可获得,不需要冗长的流程,不需要预算部门的审批,立即就可以投入创新实验、持续改进和采纳新的方法及工具。要在机制上支持动态资源分配,组织需要做的是给团队明确的方向,正确的价值观,找到对是否取得进展可量化的衡量指标,同时给团队设置一个边界,比如不能违反的规则,在一定时间段内的出资上限。当团队要开展新的工作,只要有助于实现目标,出资总额没有超过上限,工作就可以立即开展。

4

出资决策权力下放

从另一个角度讲,这必然需要打破传统企业的集中式出资决策,必须将权力下放到真正最了解实际工作,最有创新激情的一线团队。团队有足够的自主权力在组织所设定的边界范围内将资源投入到当前最有价值、最有助于实现目标的地方。

工作不要求与事先的计划相符,有充分的自由和能力去执行。只要通过可衡量的指标体现出团队正在实现组织目标和愿景的道路上不断取得进展。如果持续没有进展,那么后续的出资就将面临问题。这里上层组织对下层应当坚持一个"辅助性原则",即上层组织只有在下属部门无法有效做出决策时提供辅助,否则就应当放权;同时上层组织要有能力对实际的支出和进展进行监控。

各级组织要有能力自主决策,整个组织就需要大力支持内部的信息透明和共享。越是信息封闭的系统就越不得不将所有的决策交由最上层来制定,而带来的就是整个组织的低效,僵化。

瑞典商业银行曾经举步维艰,客户纷纷在银行业变革和大量小银行的竞争冲击下流失。于是瑞典商业银行请一位小银行的创始人瓦兰德来担当CEO。瓦兰德上任后进行了一系列改革,其中最重要的就是实行激进的分权化,并且完全摒弃原有的预算编制流程。

各分行的经理有很大的决策权,一个客户公司的所有额度都由与其存在客户关系的分行经理决定和控制。这给组织带来源自一线的快速适应力,使得各级领导者不再专注于详尽的预测和计划执行,而是关注于客户服务和持续改进。对各级管理者的考核不再是预算的完成情况,而是对齐组织真正的目的和收益,比如总行、分行的权益回报率、成本收入比、人均利润率、全员利润率等成效指标。

当然这样的分权管理体制需要有与之相适应的企业文化,减少约束,原则重于流程,以及严格的财务监管体系和中央信用体系。最终瑞典商业银行的改革成效卓著,极大提升了客户满意度,在同行业中权益回报率与花旗相当,而不良资产率非常低。

其它进行了类似预算制度改革的还有丰田汽车、西南航空等。现在很多互联网企业在激烈竞争和追求创新的激励下也在积极探索和采纳超越预算的方法,比如Facebook。根据CIMA的一份对英国企业的调查,有超过55%的企业在尝试对传统预算制度进行改革,尤其是让基层管理者更多参与到预算决策过程中,给予更多自主性。

5

持续小额出资有利创新

在和有些企业管理者交流时,听到他们抱怨:在新产品和服务上投入了巨额资金却还是失败了,而一些创业企业没有多少资金却做出了令人喜爱的产品;有些创业企业在取得一些积极进展后,就收到了来自投资方百万、千万的资金支持,用于扩大团队,然而不少这样的团队和产品很快就死掉了,大量资金被浪费。

对于投资规模和创新的关系普遍存在一个认知误区,那就是“创新必须依靠大量的投资”,在企业组织、社会中普遍有这样的观点。不可否认,没有资金会让所有事情都举步维艰;并且多少资金算多,多少算少也因产品特征而无法简单界定,需要投资者去思考;但资金的多少和创新是否成功之间没有必然联系,甚至过多的资金会阻碍创新。

诞生于英国剑桥的ARM是一家芯片设计公司,自己不生产,只对外提供授权。其最初版本是上个世纪80年代两个英国人Sophie Wilson和Steve Furber设计的,相对Intel芯片其最大的特点就是低功耗、低成本和高性能,如今像高通、诺基亚乃至苹果的芯片都是基于ARM的架构,它所设计的芯片如今已经成为几乎所有移动设备的心脏。

当ARM的老板Herman Hauser在接受访问时被问到,“为什么ARM能做到,而当年的Intel,摩托罗拉却做不到”时,他说:"回过头来看,当时在我们决定做一款微处理器的时候,我认为我做了两个重要的决定。我信任我的团队,并且给了团队两件Intel和摩托罗拉永远不会提供给他们员工的东西:第一是缺钱,第二是缺人。他们不得不保持简单。"

我们必须清醒地认识到,创新的想法大多数都是错的。在创新的早期阶段,最重要的事情是通过实验降低不确定性,从技术、设计到商业模式的各种不确定性。有限的资金加上迫切想解决问题的创新者会将所有的精力聚焦在用户,而不是某领导或自己随意拍脑袋想出来的想法;对每一分钱的珍视才会让创业者用心去发现和投入到最有价值的工作上,让一切尽可能保持简单。这对于任何产品的研发都至关重要。而过多的资金很容易让团队脱离对用户、对价值的关注,开始挥霍资金为所欲为,开始不必要地过早走向规模化。

对于一个组织而言,什么才是创新最需要的?它更需要的自由的环境、生机勃勃鼓励试错的文化,需要那些富有激情的、全力投入的的团队,需要和用户建立紧密的联系,而这些条件和大量的投资并不太相关。

支持创新和有适应力的出资决策应当是持续的、小额的。采用动态资源分配的方法,采用小步快跑、步步为营的策略,用心地培养和关注早期用户,基于真正与组织愿景、关键用户和业务成效相关的量化指标对创新探索所取得的成效进行衡量,随时准备修正解决方案,甚至停止投资。我可以给你一个有趣的办法来评价一个产品是真的创新,还是模仿:如果它的成功是在短时间内靠大量投资促成的,那它就是模仿。

6

围绕业务,而非按职能进行出资决策

最后,要支持组织的各层级能够自主灵活地进行有效的出资决策,进行动态资源分配,必不可少的是对成本和投资产生的收益进行实时的衡量。这在强职能化的组织结构中非常困难,按职能部门进行的预算和成本支出很难清楚地划分到各个业务线或产品。只有组织治理结构完全向业务、向产品看齐,才有可能清晰地计算出投入在每项业务或产品上的成本。

从全局来看,我们要将精益和敏捷的思想和方法在组织中规模化,仅仅在产品和团队层面进行改革是不够的,产生不了其应有的收益。组织最终目标是要能持续创新,具备灵活性和适应力,最大化的创造用户和业务收益。这需要企业经营者将精益思想运用到企业运营层面,其中最重要的因素之一就是财务预算和出资能够具有足够适应力,能够快速灵活调整,聚焦于用户服务而非内部流程和考核,从而唤起组织创新活力。我一个同事开玩笑说"钱敏捷了,什么都敏捷了",其实道理就这么简单。


本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-10-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 思特沃克 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
持续集成
CODING 持续集成(CODING Continuous Integration,CODING-CI)全面兼容 Jenkins 的持续集成服务,支持 Java、Python、NodeJS 等所有主流语言,并且支持 Docker 镜像的构建。图形化编排,高配集群多 Job 并行构建全面提速您的构建任务。支持主流的 Git 代码仓库,包括 CODING 代码托管、GitHub、GitLab 等。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档