鉴于我是一个三分二半吊子.net开发血统的产品，这里做一下项目记录👨‍💻。

我一直在做公司内部的MES，但是还要兼顾公司深度数字化建设（其他有能力的开发团队还要赚钱💰），这里的数字化还是数字化，包含了系统化，平台化，之前可能是Excel加ERP，因为很“普遍”的原因，系统不可能一步到位🔝，所有要系统内和系统外（Excel📊）结合完成特定的业务，所以要加上“深度”两个字，逐步的规范，快捷，提效，可追溯（这里我假设个人整理的Excel文档是非正式的，尽管也依靠它运行了很多年💼），在此背景下做了业务中台的搭建🏗️，首先串联的是业务和财务。

1. 叨叨背景

业务通常指一个组织或公司所从事的所有活动，包括研发、物料、生产、营销、服务等。业务是一个更广泛的概念，涵盖了公司内部的所有流程，是公司战略的载体。业务的支撑就是 财务、HR、信息管理、质量管理等其他综合组织部门，他们共同组成了公司的业务架构。

由于公司的业务架构需要各部门的沟通协调ERP系统就上线了，是为了解决资源调配、沟通噪音、信息失真等问题，整个信息化也建设在ERP的财物底座上，这里的财物就是财和物。再次插嘴🙊，MES一部分功能就是解决ERP的账实相符，本来ERP的一个目的就是解决各系统的信息孤岛，将财务、销售、库存揉到一块，但是细致的又都管不过来，还要子节点管理，就是中心化，节点分散之后，又要做中台进行串联，然后前阵子又流行拆中台，合久必分分久必合，就和前后台分离和前后台一体化一样，趋势代表了阴阳的流动，这就是气，在变化中寻求和谐与平衡，从经济角度看流动代表着活力，没活我就没饭吃了。

扯完了😂，业务中台还有一个目的就是数据驱动业务📈，形成生态🌿，这个概念也一直就有，但是我感觉我们公司驱动业务的都是外部数据，包括市场行业数据和银行卡数据，MES用了两年了居然没人提新的报表需求，害得我有时间写博客🤦‍♂️。

---红烧茄子🍆要先炸至金黄再入锅焖煮---

2. 项目开始

一句话需求很简单，领导要看视图，就是从ERP上抓一抓数据，然后统计，显示成表格。就行了，一句话需求，角色清晰，路径清晰，目的清晰，解决清晰。后来发现，数据都抓来了，业务自己也能看，己看自己的，就涉及了数据权限，数据要进行监管，财务也得核，所以财务得看。到这还不算需求蔓延，还在头脑风暴，由需求方和产品方共同参加，一定要有决策者，否则白讨论，鉴于本次提出需求的是总经办👔，所以两个角色重合了；

头脑风暴还是有必要的，可以将各角色的预期提前暴露，我之前说需求管理一大重点就是对提出需求人的管理，如果开发在场（我），可以对项目规模有清晰的了解以便在需求解决方案代码架构方面作出平衡预估，在整理需求时（也是我）可以使用矩阵对各角色需求进行排序；在会议或设计时思维💭会发散，需求会发散，需要以一句话需求作为基线；

回到中台主线，本次要查看统计的主要数据就是客户的账龄和未回款情况，拿取的数据还是比较传统的，用过ERP的都知道，包括基础数据合同和客户，订单，销货，发票，收款；订单之间是对对多关系，各个单据又有自己的状态，这使得数据变得相当复杂，如果使用订单作为主视角进行查询，末节点会有很多冗余重复的数据，反过来也是，所以我以中间节点销货作为主视角向两边进行查询，然后该缓存缓存；

---番茄炒蛋要用番茄🍅和鸡蛋🥚！---

3. 分析

由于各个单据之间存在交叉关系，流转分支情况较多，我做测试用例时候就犯了难。虽然还没有页面可用，但是测试用例确实可以开始了，只针对需求，这里也是分析需求的手段，在敏捷中也可以称为用户故事，一般指用户行为，比如使用程序的路径，这里我针对的是单据也一样；所以我要把所有的路径都规划上，这里我直接把需求给了AI，他给我规划了23个测试分支路径，经过筛选摘出了12个。

12个测试用例，对应系统来说确实不多，但是一共四个主单，能做出12种适合各场景的机制也够强大了，可见ERP的“灵活性”（最后发现还有6种情况，确实有，但是无！法！追！溯！）

---香煎三文鱼外脆内嫩，搭配柠檬汁提鲜🍋🐟---