前阵子偶然机会认识一个新朋友，互相聊到工作，然后我自我介绍自己目前的工作领域是电商中后台，为了方便对方理解，介绍说可以理解为ERP。结果很尴尬的是，对方就是专业做ERP的。再往下的聊天就很尴尬了，例如说对订单、供应链的管理，我们跟真正的ERP，例如SAP和ORACLE厂商产品之间，肯定有不同，或者说差距。而之前的工作中，对SAP或者oracle或者国内的金蝶之类的了解也不多，还是只在看自己的一亩三分地了。
现在的公司A有一个ERP系统，用的oracle，跟其他同事讨论过之后，了解到是不支持具体的业务操作，只记录状态和结果。具体内部的逻辑对我们下游系统是黑箱。在这套ERP系统外层，营销线这边我们自研了一个系统III，有订单、供应链以及财务销售、开票等模块，而且逻辑会更详细，举例我了解的多一些的供应链这一块，会有例如齐套等概念。这个系统可以理解为A公司实际支持业务操作的ERP。
而在III系统之外，近几年把电商类业务抽离出来，自研了一个新系统E，负责管理电商业务的订单、库存、调拨、销售、发票等业务。这就是目前所在的部门日常研发迭代的系统。但光是这一套系统，里面涉及的内容就非常多，最核心的订单、供应链、财务处理等逻辑经过了几年的添（wa）砖（keng）加（tian）瓦（keng）之后，已经没有一个人能够完整了解到整套系统的细节。单个产品最多能够了解到其中的1-2个模块。尤其是里面的销售明细、销售单逻辑，大的逻辑框架一堂课可以讲完，但是模块中字段的关系，内外部逻辑约束，真的只有当时做这个东西的人才知道了。
个人现在对这套系统中的供应链管理，调拨操作，事前配置，事后处理等比较熟悉，但也仅限于此。离去年我们想建设的“全链路人才”差距很多，如果要在现在的基础上延展知识边界的话，周围是这几点
1、供应链的业务逻辑。现在的工作流程中，是要求业务部门明确好自己的业务方案之后，再给到IT，由IT部门确认具体的IT开发方案。这样做的好处是分工细致，对IT来说比较轻松。缺点是IT对业务的理解可能不够深入，更多是站在IT的角度去考虑如何建设系统，对具体的业务逻辑，业务操作体验等等都可能存在遗漏。有个口号叫做“要比业务更懂业务”，知易行难。
2、周边模块逻辑。例如供应链管理的业务目的是“有货卖”，那接下来就涉及到具体怎么通过“订单”去把货卖出去，货卖出去以后，怎么把钱收回来，收回来的钱跟对应的订单应收如何核对。电商管理系统的核心内容“订单管理”“售后管理”，我现在能说清楚一个大概，但是更详细的具体场景怎么处理，系统上怎么操作，就没法去做指导了。“财务管理”也大概是这样，对财务管理的框架图，数据流怎么走，可以说个大概，但是没法去作指导。
3、上下游系统。具体说就是下游的WMS，以及上游的ERP或III系统。现在想要覆盖那些领域，需要真的有那个环境去做这几个系统才行。不太现实，意义也不大。
这样看来的话，现在需要操作的就是上面的1、2点。重点去了解下业务逻辑，知道业务日常工作都在干些啥，关注啥。而不只是拿着业务给的结果来想怎么做系统。另外，周边模块逻辑，现在可以通过看help文档和其他资料来帮助自己梳理一遍，字段级的逻辑是不可能掌握得到的，但以“产品视图”的角度，去看一遍系统能力还是需要的。
补一个图
