Palantir本土化的几个问题

1、强大的平台与强大的实施团队相辅相成。

    首先，FDE模式并不是一个完全新兴的概念，只要做过低代码平台(包括工业界所谓的组态软件)，基于这些低代码的实施团队都是所谓传统的“FDE”。其核心是解决用户需求和基于产品的灵活配置\开发的现场团队。这样一个团队的平台前提是，这个平台需要高度抽象且灵活，能够满足用户端不同的需求，而且要快速。这里面除开需要平台灵活以外，原则还需要有很多的“预制库”。很多时候平台打造容易，库打造很难。也就是说Palantir平台复制对中国的工程师来讲并不是难事，而库的复制那就很复杂了。

2、实施团队实际上是八爪鱼式的超级个体

    传统的面向IT的业务低代码平台对实施人员的要求没那么高，因为这种流程表单型业务相对容易理解，而且是非常IT的语言，与平台技术需要的能力高度相似。而传统SCADA（特殊的低代码）平台对人的要求往往会更复杂，因为自动化和IT离得更远，而且现场往往是一个“全栈工程师”干所有的活儿。这种情况下，要不基于SCADA的HMI画面做好，我们会发现是一个非常困难的事情。

    而对于AI系统的FDE工程师，其能力要求比前面两种更为复杂，特别是面向工业领域的FDE，其往往需要具备IT、OT、ET、AI等跨领域的知识，对于交付人员来说，每一个都是超级个体。现在流行说是Π型人才，而FDE要比Π型人才更综合，可能是“八爪鱼”人才。这些人每一个拿出来都能单独成为一个公司。而这样的能力是非常难打造的。而这样的FDE能力需求如何实现跨行业的快速增长是一个值得思考的问题。

3、FDE超级个体带来的管理问题

    一方面，交付侧是超级个体，其综合能力往往要远高于后端的产品研发团队。这时候前后端的能力是不平衡的。公司层面不仅仅要在待遇方面有差异化处理，而且还需要在公司内部推动以客户为中心的文化。有个不好的例子是，有些互联网公司想要做制造业，往往在前端招了很多具备工业背景的领域专家，而后台是大量才工作不久的产品和研发（互联网年轻化）。这时候不仅仅大家行业背景有差异，阅历等都有差异，再结合公司内部产品和研发的强势氛围，结果可想而知。现在很多企业要么是销售很牛，要么是研发很牛，我似乎还没看到过什么企业是交付很牛。

    另一方面，前端的超级个体必将带来人员流动性的问题。也就是前端的人做过几个项目或者做了几年以后这些FDE必将面临大量的流失，人才团队属于不断招聘不算流失的动态调整状态。之前有个朋友做的是海外的某种定制化项目的方案负责人。他们需要的人也是需要复合型人才，但是公司薪资待遇肯定是无法与Palantir的FDE对比。所以其采用策略也非常有意思，就是大量招聘应届毕业生，这些毕业生平均生命周期为三年，三年后就会跳到更有薪资竞争力或工作没那么复杂的企业。三年时间内，第一年是学习（公司是赔钱的），第二年实战（不亏），第三年能够独当一面（公司能争取）。然后不断去循环这个过程。

   4、高付费意愿客户缺乏

   FDE前面这些特点要求每个项目都是高利润的。现在国内的交付环境简直一言难尽。有些所谓的国外的咨询公司用其品牌拿到一些项目以后，往往在交付阶段全部安排刚毕业的大学生去做。一方面甲方的咨询费确实不高，另一方面目前大部分的企业的思维仍然是项目型交付，而且对实施过程不重视。这样双方都在卷的市场是无法生长出Palantir这样的业务的。

    不说几亿美金甚至几十亿美金的客户，我们想想有没有原因每年持续出几千万咨询费的客户？

   5、本体需要更高成熟度的客户

    Palantir的本体并不是什么新奇的东西，这样在不同的领域用不同的概念一直在推进。很多时候推不动的原因不在于这个平台好不好，而是企业的成熟度没有到那个阶段。我们总不能告诉一个还吃不饱的人说吃素更健康吧。所以，没有高成熟度的客户，平台无法与企业实际情况匹配，平台越高级，对于企业来说越是累赘。再者，本体是典型的自上而下思维，这个与中国大部分工程师的习惯是冲突的。

     6、东施效颦

   现在网上非常多分析Palantir的文章，大部分还停留在功能层面。而更搞笑的是，很多文章下面都有人留言回复说某某公司正在复制Palantir的功能。然后去这个公司网站一看还是在做传统的数据平台。简单的功能复制都做不到，何谈灵魂的复制？

    下次谁在说要复制Palantir，请show出你的平台、“库”、交付团队简历、项目合同金额。

   本体好啊，该怎么做？用什么建模语言？如何做本体化的平台？如何积累库？如何构建FDE团队，如何持续运营。这个应该是一个复杂的话题。有兴趣的大家可以私下讨论。或者说，提出了问题就已经表达了我个人的解决思路。