新媒易动态
NEWS CENTER
NEWS CENTER
2020-12-29
不管效率是来自科学分工,还是协同管理,其落实到实际操作层面都需要相应生产工具来支撑;因此“后台工具”是组织生产关系的载体,是组织效率的基础设施。
举个例子:村子里有最好吃的大米种子,且市场对此大米供不应求,村民都是种地能手;But!镰刀锤子收割机不好使,你说这事咋弄呢。
那么后台系统是如何影响组织生产关系的呢?
举几个例子:
例1:严重缺失的后台系统,让团队协作效率极低。
无财务系统,财务管理全靠EXCEL,从销售,到运营,到财务,到领导,全部靠人工传递,Execl记录;这样不仅会让各个环节的沟通协作效率低下,甚至会直接导致“财务误差”“财务造假”等有损组织利益的后果。
当然是否需要完善支撑系统,还得考虑组织发展的阶段,例如:在产品初期或者创业型公司或者比较边缘的部门,由于优先级和资源有限,只能靠人力线下协同。
比如我经常听到的一些话:“你的产品能不能活过今年都不知道呢,做什么财务系统,先人工搞吧”,“要不先随便整个小工具临时用着吧”。 当然不存在对与错,核心在“权衡”。
例2:繁杂的后台工具,让部门沟通成本陡增。
或许你有这种经历:做一件工作需跨越多个系统,使用多套账号,和多人沟通。——独立工作被系统切割成多个片段。
例3:没有经过高度抽象的后台系统,灵活度低,严重拖累业务发展效率。
年终规划,BOSS:明年的商品组合套餐A+B+C,销售策略X,Y,Z,奖金提成方案Z,为了支撑明年的年度规划,必须在年前完成后台系统的升级支撑。
产研团队加班加点,过年都差点没回家,终于完成了。
3个月之后,商品组合策略,销售策略,提成管理方案全变了;此时小则迭代功能,大则需要改版重构,严重拖累业务发展效率。
市场和管理的变化是无法避免的,而聪明的产品经理需要识别影响变化的最底层因素,然后层层抽象产品设计,为研发提供灵活的架构设计;可以做到随着业务的变化灵活配置,高效迭代。
例4:分散的后台工具,严重损伤用户体验。
每个部门都有自己重要紧急的工作,这项工作只是各自边缘支撑工作,响应效率必然低下;邮件,微信半天后才回复,甚至完全被遗漏。
于是半天过去,一天过去了…
因此从这个角度,“后台系统”绝不仅仅是为了“支撑业务”,而是整个组织效率的核心保障。
精心设计的后台体系——让组织协同效率1+1>2,没有经过深度思考的后台体系——让组织效率1+1<2。
如何规划建设后台体系,才能尽量避免上面的4个例子?下面为笔者的简单总结,如有不足,欢迎读者指教探讨。
产品经理岗位,从初级到高级的过程,某种意义上也是“产品视角”迭代的过程。
1)功能视角
产品实习生/助理:接到某个任务,完成某个功能点的设计。
2)单产品视角
某个产品模块,或者某个产品的负责人:整体规划产品的不同模块的迭代计划。
3)多业务视角
高阶产品经理:不仅仅关注产品本身,与产品相关的:运营,市场,销售要全局关注。站在“整个业务的视角看产品”
4)多产品多业务视角
产品主管/总监:负责多个产品多条业务,权衡企业战略,顾及多个部门。全局规划管理“企业产品矩阵”。
虽然会随着经验,关注的层面不同。但是作为产品经理,哪怕你目前只对一个单点功能负责,如果可以,也一定站在全局的视角思考问题。
产品仅仅是解决某个现实问题而产生某种“价值”,但是实现这个价值需要:识别定义价值(产品)、实现价值(技术/生产部门)、传递价值(市场/运营部门)、交换价值(运营/销售部门)。
而这个从价值定义到完成价值交换的过程,是企业内部不同属性的生产力,通过不同方式的生产关系,使用不同的生产工具协同进行。
因此当产品经理在设计组织“生产工具”时,首先需要有“全局观”的认知高度;哪怕最终交付的成果是受限于优先级和资源瓶颈,而不得不做的取舍,那也是从“组织效率”全局考虑后的取舍。
所谓业务调研,就是彻底搞清楚你所做的系统涉及到公司所有相关部门/相关人/相关系统,以及他们的工作内容,工作目的。
比如,如果你做的是一个财务系统,涉及到的系统:商品管理系统、订单管理系统,甚至还有运营/ 销售人员的绩效管理系统、供应链、人力资源等等。
同时涉及到的部门可能有:财务部、商品订单管理部、运营部、HR部、销售部、BOSS团等。
还拿财务系统举例:财务最核心的就是“营收”和“成本”,这里只从“营收”端举例。
你可能需要搞清楚几个问题:
不同的商业模式,决定不同的销售模式。这里我们用ToB的商业模式举例,因为要比toC的模式更复杂。
销售:拜访客户,介绍产品,拿下客户后应该会有下面几步: