半年前和猎头聊天，他说你的抬头里有个 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的面试我第一次清晰明确的提出自己的定位。虽然不太看好这家公司目前的创业项目，感觉犯了典型的创业公司的错，但是也反思为什么他们会看中我。我的反应以及谈论问题的角度以及方式，或许符合了他们的期望：运营。
不由深深体会王信文对参加别的公司面试的建议：站在他人的视角，更加了解自己在整个行业中的位置，面试官的问题可以作为自己成长的指南针，最后面试是否录取的反馈，也会帮自己改进，而且主动去接受这些反馈，会很痛苦。
深以为然！
阅
网友评论