“四大”的精细化管理工具:填报工时
2023-09-05 07:59

“四大”的精细化管理工具:填报工时

本文来自微信公众号:小圈生活之(ID:Big4sHiNe),作者:趙耀,原文标题:《职场篇:填报工时》,题图来自:视觉中国

文章摘要
本文介绍了在“四大”工作期间填报工时的精细化管理工具,以及工时统计和计算方法。文章还提到了工时的分类和解读,以及工时成本和收入确认的相关问题。

• 文章详细介绍了“四大”工作期间填报工时的标准成本法和精细化管理工具。

• 作者解释了工时的分类和解读,以及工时成本和收入确认的相关问题。

• 文章提到了在工时管理中的一些应对策略,如合理安排工作时间和提高收费等。


填报工时,用会计上的语言来形容那就是标准成本法,是在“四大”工作期间每两周就使用的精细化管理工具,非常值得学习和借鉴。


众所周知,一个人正常一年工作的标准工时是2,080个钟。这数儿是怎么来的呢?一天标准工时8个钟,一周5天,一年一共52周。于是8×5×52=2,080。


可能会有朋友说了,那元旦、春节、国庆等法定假期呢?


别担心,“四大”的标准工时法都已经考虑到了。法定节假日都有专门的Code供填写,扣除这些法定假期,剩下的标准工时统称为:Available Hours。


Code可以简单理解为项目名称。



上图是我2016财年、2017财年和2018财年的工时统计。


那为啥不展示近几年的数据呢?是因为在2018财年过后我就“隐退江湖”了,这是另外的故事,以后再表。


继续说回标准工时。“四大”对于正常的年假、产假、婚丧嫁娶等福利都有专门的Code供填报。


公司提供的培训、无论是培训还是授课,也有专门的Code。关于培训的工时统称为:Learning & Growth。


至于PD,它是Project Development的缩写,也就是投入到项目竞标的实际工时。


在安达信年代,还有为出差路上花费的时间而专门设置Code——Travel。但这个并没有延续下来,可能是因为出差路上都可以打开电脑工作或参加电话会议。不能太精细,否则就执行不了了。


上述这些Code都属于不能向客户收取费用的工时,它们总称:Non-Chargeable Hours。


所以如果不考虑加班“OT”(即Overtime),一年下来,每个人的有效工时率“UT”(即Utilisation,用Chargeable Hours除以Available Hours得出的比率)一定不到100%。



今儿重点说一说Chargeable Hours


对个人而言,它是记录时间的有效工具。


在我曾经工作过的“四大”之一,项目管理会赋予每家客户一个唯一编号——Client Code,在这个客户编号下是不同的业务编号——Engagement Code。


举个栗子,某大型金融机构的客户编号是1004704。在这个客户编号下是不同的业务编号,例如年度审计业务编号是BJA3501-A01,期中审阅是BJA3511-A06。


具体的业务编号可不是系统胡乱生成的,它对于公司以及合伙人而言非常重要。后面会细说。


事务所里的每一位专业人员每两周都需要填报工时,填报的基础是实际为客户提供服务的有效工时。


比如一位同事被Book在A客户的年审里,那么TA需要将自己的实际有效工时记录在A客户的年审Code里。如果TA后来又被Book到B客户的年审里,那么同理进行操作即可。


一个财年下来,TA的UT就可以计算得出。


对于UT的解读,我曾经写过一篇小作文,有兴趣的朋友请移步到:职场篇:解UT的高与低


当然, 有效工时是一个理论值。毕竟现实中不太可能准确统计出这个数字,只能说是一个相对合理的数值而已。


正常情况下,出勤一天可以有8个钟的有效工时。尽管项目经理和合伙人都明白,8个钟里肯定有上厕所、吃中饭、等候客户资料、聊天、吃零食等等不可控因素,但架不住在忙季谁也不会准点儿下班啊。


至于加班到几点和能有多少个钟的OT,不仅仅是有没有效率的问题,更多时候是看项目的“肥瘦”情况。


肥项目就多给一些OT,但安达信时代的据实列支一去不复返。那时候加班狠,但给的OT也很痛快。当然这都是大家将心比心换来的。


后来随着劳动法的进一步细化,每个月的OT不得超过36个钟,简单计算是每天不得加班超过1.2个钟,这对于忙季的审计师来说,怎么可能?


于是就有了相应的政策。那就是每月OT的前36个钟,小朋友们可以自行选择:加班费或者1:1的调休。至于每月超过36个钟的部分,没得选,只能是调休。


瘦项目就相对吝啬一些,小朋友们不乐意,合伙人也不乐意,公司更不乐意。但不太会一年下来所有的项目都是瘦项目嘛。


对公司而言,它是反映收入成本的方式方法。


一个项目的好与坏,除了管理层诚信很重要外,还要看管理层是否积极配合审计工作,治理层是否支持审计团队并且为审计团队争取更加合理的审计师薪酬。


其实好的项目管理在参与竞标的过程中就充分介入了。特别是报价环节,当报价单确定的同时,项目的毛利率水平基本也就确定了。


举个“栗子”:在竞标某一个项目的时候,需要投入的人力资源是确定的,它是根据项目的复杂程度、时间的轻重缓急以及能否有足够的人员来参与决定的。


在“四大”,每一类级别的同事都有标准的工时成本。例如合伙人每个钟6,000元,高级经理每个钟4,500元,经理每个钟3,000元,助理人员每个钟1,200元等等,实际细分会比这详细得多。(以上数据如有雷同纯属巧合。)


当项目所需人员的级别和数量确定后,标准工时法下的总成本也就计算出来了。


例如需要2位合伙人投入100个钟,4位经理投入200个钟,助理人员20位投入1,000个钟。那么总成本就是27,600,000元。


有了这个基础,那报价就好给出了。打五折就是1,380万,打二五折就是690万,打一折就是276万。


接下来就引入“RR”(即Recovery Rate,用收入减去税费后的净额再除以成本计算得出的比例),用来衡量该项目是否值得争取。


我曾经有一个基金项目,它业绩很好,财务人员口才不错,就是干活儿差点儿意思,财务记账很混乱。每次审计团队进场后,都先要重新梳理一年的交易才能形成工作的基础。


基金合伙人也不错,可始终不重视财务这条线,管理建议每次都虚心接受,但就是不改。审计费还不给增长。


M经理和小朋友们做的很辛苦,项目RR实在太低。于是我决定主动放弃这个客户。何必呢,把我的同事累得够呛,还只收仨瓜俩枣儿的钱。


当出完最后一本审计报告时,我让M经理和客户沟通,明年不再为他们提供审计服务了。早通知客户可以让客户早另行安排,别互相耽误。


看得出,同事们很开心。


客户方面很快有了反馈,又是电话又是约见,反正希望继续合作,甚至是表明可以适当提高审计费。在我委婉拒绝了多次后,有一天公司副主席居然电话我询问这个事儿,我一句话断了TA的念想:风险太高,不宜继续承接。


事后M经理和我聊天,还担心客户涨价、找领导后我会妥协,我嘿嘿一笑:不能太辛苦大家,咱不差钱!


至于缺点嘛,工具本身没有什么问题,有问题的是人。



权责发生制 vs.收付实现制。


提供审计服务与收入确认是这样的。甲乙双方签署业务约定书后,甲方按照约定的实际支付审计费,通常比例是5:4:1,也就是乙方入场时支付50%,完成审计报告草稿后再支付40%,最后支付剩下的10%。


这个比例不是固定的,因为现实情况很复杂。有些甲方店大欺客,审计工作快完成时才支付大部分款项;也有的甲方怕付款申请流程麻烦,选择一次性支付,总之就是林子大了,什么鸟都有。


这就造成事务所在收入确认上的一个难点,那就是每个月记录多少收入?


权责发生制下,“四大”采用的标准成本法和预期RR,就能完美解决收入确认的问题。


每个月根据上项目人员的级别和数量,以及对应项目的RR,就以数学的方式计算出每个月应确认的收入。很有道理吧。


然而这也带来另外一个问题,那就是审计工作往往开展在年底,结束于年初,大约每年10月开始,次年4月份结束。那么剩下的月份每月项目怎么办呢?


解决方案有三:


1. 合伙人多跑市场。一个IPO项目中期也是要申报的,这可以充分利用现有人员。此外还争取“短平快”的项目,在我们称之为Slack Season的期间,即5月份至9月份,也把人员充分利用上。优点是增加收入。缺点是大家马不停蹄。


2. 现有项目前置。预审工作提前,实现动态审计,意思是不要集中于年底开展工作,时时刻刻地参与。优点是增加了客户粘度,时刻需要审计师。缺点也很明显,大家马不停蹄。


3. 先开Code再铺人。具体如何安排工作那是每个合伙人的事情,上面要的是减少Idle Hour或安排休假。毕竟有时候是真没有新项目或者客户不允许提前那么多时间就预审。这是下下策。优点就是没有优点,缺点就是全是缺点。


遇到这种情况最麻烦,但是,古人云:上有政策,下就有对策。


通常会和中期没项目的同事谈话,如果不想这个时候休假,那么就去IPO项目里锻炼锻炼,前提是不要带着打酱油的心态去学习。这样安排可以让原本IPO项目中的同事压力减轻,二来也可以产生收入。


明眼人肯定会想到,这样IPO项目的RR不就降低了么?不会的,新加入的同事会安排Charge在自己年末即将参与的那个项目Code中,因此不会增加IPO项目的成本。


但这样会增加年末项目的成本,毕竟Charge了它但没有为它工作。解决方案就是提高收费,维持RR不变。


尽管这和项目管理的正确理念不同,但是没办法,不能这也要,那也要,要啥自行车!


哎,明明一个收付实现制的业务模式,非要调整为权责发生制模式,那中间总得有个过渡过程吧。


后来事务所改进了内部管理,规定开立新Code,必须要有业务约定书为支持性文件。于是,解决方案只有第一条路可走了。


话又说回来,上面这些“对策”我可从来没用过啊,信不信由你。


本文来自微信公众号:小圈生活之(ID:Big4sHiNe),作者:趙耀

本内容为作者独立观点,不代表虎嗅立场。未经允许不得转载,授权事宜请联系hezuo@huxiu.com
如对本稿件有异议或投诉,请联系tougao@huxiu.com
正在改变与想要改变世界的人,都在 虎嗅APP