“合”与“和”—— merger, harmony, orchestration
两年前，在IHS和SP合并交易正式完成的时候，我曾经简单地写了一篇《大浪淘沙》的小文，来纪念IHS的存在。
经过这两年实际的体验，的确验证了当时的一些感叹和担忧，当然也更加具体了些。最近和不同业务部门、不同市场、包括已经被剥离在外、和其他外企的同事交流，发现大家的感触都类似，并且也不仅仅是我们的公司，美国企业的“MBA”治理现象高度趋同。“合并”——Merger一词，也许的确符合美国人的文化，但世界的自然规律和业务生态，或许更需要东方的“和”——和谐Harmony，或者说用英国人比较装逼的词汇，“和弦”的和——orchestration。
硬和软的事实 – “洞察”形成的必要非充分条件
两边合并之后，自然产品和平台也在整合，但似乎并非一种整体性、有机的结合。而是直接简单地拼凑。例如两个预测模型，便都保留，形成“alternative view”；更多的情况是通过增加单点登录的方式访问，也就是增加一个超链接。似乎这也并非SP收购IHS的操作，之前不少他们的解决方案，似乎都是以这种方式来继续提供服务的。包括Panjiva依然独立，界面也保留着原来的个性。从周五微软CrowdStrike Bug引发的宕机影响了一部分服务、另一部分未受影响也可以看到，各个系统之间的库并未统一，仍然是散装的。
但更主要的是，两边的数据的确存在不同。即使是在转到CI之前，就已发现海事和贸易数据（MT）、与国别风险与经济（ECR）的存在很大的差异，所以当两边合并后以GIA这个含糊不清的业务分支名称继续运作时，事实上依然各自做各自的，并未形成太多的协同效应。个人猜测，初衷是上面看到“供应链”“风险”这些引起精神高潮的字眼后，便觉得这两边应该有所交叉。但事实并非如此。一边是直接来自船舶、港口的“元数据”，颗粒度到每一艘船、每一个泊位、甚至每一个机械装置、每一家公司；哪怕是贸易端，也有每一票单据、或是至少是每个月、每个细分商品的品目。我一直把这些称为“Hard Fact Data”- 硬事实数据（当然真实性的确一定程度上取决于源头质量）。但在国别风险和经济那一头，风险首先就是一个数值，是根据方法论的类似于“评级”的打分，尽管方法论公开，但仍然是一种主观认知的数据；而商品价格更是很大程度上以“指数”方式呈现，商品分类体系和贸易HS编码体系也是完全无法匹配上，何况覆盖面在全球市场的不均衡性很强，除了美国之外，能够拿来参考的意义很微弱。
回到航运的领域，整合后，可能也是看在“Commodities”这个词的产品名称，把Commodities at Sea这个海事贸易板块的产品划给了CI，并且仅仅是这一个产品，底层的贸易数据、船舶、港口、定位，仍然留在原有的业务部门。后文再提这些。那么整合成了“航运”，包括的数据一方面有CAS这些“硬”数据，而本身SP的数据指的是什么呢？是所谓的市场估价，对航运而言，也就是运费价格，这些我也称为“软数据”，因为都是编辑团队通过和市场参与方交流最后汇总的，尽管有完善的估价方法、人群效应也的确能够反映市场状况，但毕竟它的来源和取样的条件，让价格依据仍然更建立在对“人”的依赖之上。这可能也是CAS的贸易流产生的“供需基本面”和市场运费起伏之间很难找到一个完整的故事——或者说很难互相自圆其说。当然这的确很难，其中缺失的那个“行为经济”和行业实践的环节，可能是一个诺贝尔奖问题了。客户经常提到的反馈也就是“市场端”和我们的“数据端”之间的断层；或是“信息实在太多，的确忙不过来看，但真正的预见性内容又好像缺乏”。
当然这一定不是一家信息公司的问题。所有的服务商都标榜提供深度的“洞见”，而洞见的基础显然是少不了数据；但是数据并非洞见的充分条件，需要有专业的人通过长期对数据的观察形成的洞察力、还有在行业中摸爬滚打的经验，以及最终可能是天生的嗅觉。如今提供信息的服务商层出不穷、平台越来越好看、分析师也很容易找到，但在每一个领域能够具备这些领域知识、数据分析能力和表达能力、以及全局性思考能力的人，其实并不是很多。
统筹和独立性 – 业务单元间的协同程度
上面说到这产品拆了一半过来，底层数据还在原来的部门。外界看来或者说常人认知都应该不觉得这是个问题。但偏偏这些跨国大公司内部其实各自独立核算，每个部门有着自己的绩效指标；在真的互相独立的时候没问题，但当有冲突的时候便会维护自己的利益。从合并以来，公司层面就一直宣传要“Synergy”，要协同，也就是共享客户资源啊、互相介绍业务blabla，也推出一些象征性的激励政策，但真正看在那些激励份上，能够愿意协同的的有多少。最简单的例子，如果某个商务同事和客户谈到一半，客户提到了另一个需求，我们无法满足但隔壁部门能够满足，这种情况下会不会直接介绍给隔壁？万一客户就跑去隔壁，暂缓我这里的商务流程了呢？当然更多的情况是，客户提到的需求，销售也不知道隔壁部门有啥，所以也根本不会去关注。到了我这边的航运，因为存在底层数据共享的问题，所以很常见的就是内部冲突和重叠。因为本来就了解所有这些适用的对象和各自的特点，难免更为痛苦。知道应该卖什么，却不能卖、然后强行解释可卖产品也有价值的情形遇到过多次。其实我很无所谓，愿意介绍该卖的商品给其他部门，但毕竟我并非销售。有些人不会愿意。所以有些时候只能无奈睁眼闭眼了。
相信这也并非我一个人遇到的问题。其实本质上，这些都属于内部各个部门之间统筹和保持独立性的问题，在我们这个层面、甚至到老板的老板的老板，都是难以解决的。只有整个集团的管理层来统筹这些，但毕竟这些过于细枝末节，完全不可能到达这么高的决策层。想起JPL最近和我总说的“决策的依据，是否获取了所有应该获取的信息”也是应该考核的ESG角度。
短期业绩和长期经营 – “杀鸡取卵”是好是坏
一切的一切，都是因为“业绩是第一考核指标”，毕竟按照当前的经营模式，的确需要关注自身部门所在，这完全没有错。但另一方面，似乎短期业绩的考核和重视程度，远远超过了长期可持续的盈利关注。比较简单粗暴地把所有的东西打包，无论客户细分的业务是啥，就一股脑儿全部推给别人。
当然这种模式，对一部分业务版图特别大、综合性的客户企业来说，的确是不错的。把产品拆开来一个个增加内容，价格会更贵。从我们的角度，管理也更复杂。
但除了这部分巨头，大部分即使是500强、行业头部企业，往往也就是深耕某个领域而已。ABF的John Hibbird和我说起过，他只关心一个农产品材料，但我们想把整个农业的数据集都给他；类似的我还没有告诉丹麦船公司的红胡子大哥，他对氢氧化钠感兴趣，我甚至不愿意提 你需要买所有的化学品，可能得疯了，化学品名字都念不清。其实换位思考，连我们自己内部各个业务部门都互相独立，要采购点啥都不互相沟通，客户不也可能是一样的情况呢。这就导致，我们看来，产品单价已经压缩了，从独立产品角度事实上卖一个亏一个；但从客户的角度，又是贵得离谱，完全花冤枉钱。
不管怎么说，既然那些大集团的成功案例放在眼前，就给了上层有理由继续实施的动力，小客户对他们而言也不那么care；可能是我们比较naïve吧，反正没看明白。但个人觉得，这也并不可持续，你明年卖啥呢，靠啥涨价呢。之后大家的积极性在哪里呢。
用户认可与市场地位 – 相互成就或博弈
都说商场如战场，所以大杀四方的方式也自有道理所在。SP本身在一部分领域有很强的市场地位和作为市场价格标杆的用户刚需所在，所以借此机会攫取最大利益无可厚非。不过负面效应是当强推涨价，客户一定是不满意的，有很大一部分是没有选择。如果预算充裕，也还好，但如今就是雪上加霜，经济面临不景气、各个行业各个企事业单位、无论海内外都在砍预算的情况下，如今很多谈判仿佛在博弈。
尤其是当整合了IHS这部分本来就是存在竞争、依靠的是软实力和数据质量等基础所在的服务时候，如果仍然用“市场地位”来谈价格，就难免碰到不奏效的情况了。可以说，IHS的存在是依靠用户认可和“口口相传”，船舶行业大家依然只知道IHS，我想在汽车、工程等板块，即使现在改弦易辙，大部分客户仍然习惯性沿用IHS来称呼。行业名声的积累不是一个简单的事情，要多少年的耕耘，而要毁掉则太过容易。更何况，通过和行业大部分企业之间这种建立在互信关系上的粘性，让我们更了解市场所需，去针对性开发产品，最典型的就是在我们从提供原始数据转型Saas产品成型之前，阿雷克斯专家大爷就通过对当时海事市场的分析、和在服务Shell等大企业的过程中所发现的未来若干年的市场风向和机会，并且很有自信地把这个汇报称为”reasons to be cheerful”，根据这些发现，开发了包括风险类的洞察、海上货流这些如今的当红炸子鸡内容，这种模式，才是是服务商与客户之间的“相互成就”。
分工和汇报 – 效率或冗余
都说人多力量大、也都说优化。的确，在两家公司合并后，精简了许多人力，但同时也创造了许多岗位。比较疑惑的是走了许多干活的、资深的，却也留下了许多抬头看了半天也不知干啥的人，管理一家客户要许多人，但最后却发现都不知道谁是谁；三番五次去拜访客户，只因为每个职能都有自己的KPI统计，搞得客户都其实嫌烦了。
这些就不多提，不过内部流程非常的复杂，搞一个市场活动的周期很长，导致市场热度都消失了我们再去做这些，效果怎么可能好；而搞了之后，又要统计产生了多少机会，哪有这么立竿见影的呢。另外一些看似提高效率的“工具”实质上沦为绑住手脚的鸡肋，首当其冲就是Salesforce。我想大部分外企员工对它都不陌生，并且都一致吐槽。需要往里面输入的东西非常非常多，产出和下载功能则几乎没有。照理说，每一次客户会议都录入，那么一个月有多少次活动，自动运行报告不就完了；反而还要人工再统计；合同的增加和减少，还有人天天就拿着报表让你写理由，也不知道是公司内部哪个层面的领导，就喜欢看这些。同事说，应该成立个党群工作小组，整治内部形式主义。
从技术层面上说，SF对oppys, accounts, contract的数据关联也是非常的差，尤其是找个合同，从客户公司账户进去、找到对应的当前的oppy、在进入文档、再打开contract，结果是个PDF，就想知道元数据为何不能data-tize一下，增加互操作性。
诸如此类的文科生活动太多。更好笑的是客户报错的故障，响应机制 除了“催”没有第二种手段。提SF CASE，然后就等着，然后会有不同的人找你让你描述问题，最后的解决也不知是怎么做的，反正就让你关掉CASE。十多年前在ABF实施SAP时候至少我们用的HP QC LAB来管理系统缺陷，可当时还嫌弃那个平台low，现在发现是天花板。哪有用Salesforce来管理系统故障的？
其实纵然大家都深有体会，但也无可奈何，只能或者苟或者熬或者卷。世界各个角落，如今就是那么的不科学。用小哥的话说，就是“现在这世界不尊重理工科，很正常。”
太湖蟹寄居地 