运营?产品?

半年前和猎头聊天,他说你的抬头里有个 operational,作为KAM比较吃亏,如果去掉这个机会可以更多一些。

他说的确实符合现在大多数freight forwarder的情况,工作方向简单可分为operational 和 commercial俩个层面。传统货代里,operation的感觉就是一线操作,比较初级。commercial属于商务领域相对略高层。涉及到具体的KAM这个职位,虽然commercal & operational都必须涉及,甚至operational占大部分工作比重,可是一旦抬头上被刻意标注operational似乎意味着无缘commercial。所以看到operation KAM这个抬头,用人方会直接问有没有commercial的经验,因为人们的预判里这俩个方面各自独立。

Operational KAM中文被翻译成「营运经理」。以我的中文水平,分不清这个和「运营」有无具体差别。按照目前PA SCS的分工,前端有commercial KAM和engineer/designer负责,后端有OKAM跟进。通过这半年的实际观察,前端的2个角色在功能上确实需要,但分工有点错位。价格由CKAM和product team收集,dashboard的数据收集加工呈现由engineer做,designer的功能似乎还停留在概念上,并没有太多定制化服务的体现。铁路的上线,我按自己理解的SCS全面跟进,并且和SCS现有的分工做了对比。

海运已经标准化,没多少弹性空间。空运时效弹性太大,完全把握在所谓的product & pricing team手里。CKAM也没有太多空间进一步加工,只是划分了淡旺季以及保护仓位的限额。铁路的BD基本全盘照搬本子价和一堆线路图,但是客人的问题半年来不光一点没解决,似乎还视而不见。我在铁路product team提供的各种「基础产品」上,分析客人的痛点和平衡点。他们能解决的方面,提供足够清晰的信息帮助他们把问题简化,并且降低判断难度,也直接给出建议解决方案。他们搞不定的方面,按照他们现有的能力,提供其他 方案满足现状的同时,尽可能压缩价格和时效,灵活处理价格分界线。如果最终通过的话,公司利润不会少,其实还有大把的空间。

由此,我重新审视了Forwarder的「product team」的功能:pricing + procurement,但这2个相加不能直接=product,只能是提供可以组成product的原材料,还需要一个类似产品经理的角色把这些原材料按「需」组装成产品。我对「产品经理」的理解还不太清晰,按照《梁宁——产品思维》的画像,简单说应该是目标产品的全方位负责人(all stack)。以定制化为标志的SCS,engineer应该是符合身份+功能的「产品经理」。可是,SCS的客人需要面对多少人?1*BD, 1*CKAM, 2~3*BIM, 1~2*engineer, 2~3*OKAM,差不多8~9个人分别负责不同的方面,低效不说,这些人还隶属不同的部门,没有统一的leader,有任何事都没个人出面统筹拍板……

话说回来对于铁路的种种参与,如果和我的JD套,我做的一切也没确界,都是JD范围内本该做的。那么撇除常规对operational KAM的理解局限,我对营运经理有新的认识,营运是个长线的工作,一旦长线就绝不仅仅是简单的操作,甚至可以理解广义的营运概念包含了商务的一切。我原本不太确定我对营运(运营?)的理解是否正确,而后又看到很多互联网企业招各种「运营」,包括新媒体运营、平台运营、大客户运营等等,直到昨天在书店看到本书《我在阿里做运营》里作者对运营的理解:运营,是把一件事做成的所有人为干预。这就对了!是我理解的范围。但是在这本书里,互联网公司的运营和产品经理似乎分工有别。作者有个比喻:产品经理是生孩子的,运营是带孩子的。这和我理解的产品经理又不太一样了,不过当下决定先买俩本运营的书好好琢磨下。也许不同的行业,同样的职位定位不能照搬。

另外,上次HZL的面试我第一次清晰明确的提出自己的定位。虽然不太看好这家公司目前的创业项目,感觉犯了典型的创业公司的错,但是也反思为什么他们会看中我。我的反应以及谈论问题的角度以及方式,或许符合了他们的期望:运营。

不由深深体会王信文对参加别的公司面试的建议:站在他人的视角,更加了解自己在整个行业中的位置,面试官的问题可以作为自己成长的指南针,最后面试是否录取的反馈,也会帮自己改进,而且主动去接受这些反馈,会很痛苦。

深以为然!




























你可能感兴趣的:(运营?产品?)