闲人闲谈PS之十五——合同、项目、WBS的关系
惯例闲话：干顾问这一行，都免不了干擦屁股活的经历。对于擦屁股活，不仅仅我自己，大部分人都嗤之以鼻。可是，生活嘛，不可能一直干顺心的活，甜酸苦辣，总是如影随形。闲人最近也在干擦屁股活，只是这个活略棘手。其实很多擦屁股活的形成，都有很共同的特征，上线后实际业务和蓝图出现非常大的差异，导致业务开展不顺利，进而频繁调整或推翻已有功能，然后老顾问组一肚子怨气，人事频繁变动，最后的结果多数是恶性循环，导致项目失败。闲人在当前的这个项目，就遇到这个问题，所幸，在多年前经历过类似的场景，怎么把这屁股擦好，闲人心里还是有底。这个项目问题根源之一，用户包括项目组一开始，是对合同和项目关系，存在一定的认知盲区。。。。。。
闲话到此为止，我们说说正题，项目型企业蓝图第一个关键的龙头问题——合同、项目、WBS的关系。
合同，是绝大多数企业经营活动的开始点。
一、认识合同的重要性：
从法律上看，合同是约定甲乙双方权利义务的法律文件，企业经营要想享受法律的保护，合同是第一要务，这也就解释了为何在很多企业合同评审流程上，必然有法务这样的岗位经手。法务这部分不是的我们重点内容，但是在实际业务蓝图设计中，不应将法务排除在项目组之外，理由是：法务手里掌握实施合同的审批权，作为乙方还是要给予法务刷存在感的机会，比如合同审批流程，多聆听下法务的意见，虽然很多时候基本是充满法学术语的废话，但是我们还是要耐心。
从后勤视角上看，对于大多数企业，合同是企业维持正常运转的动力，也是企业实现经营目标的载体来源。很多企业会将合同标的物分类，如项目型企业，可分为项目型合同，合同标的物是某个满足客户使用要求的工程项目或大型装备；产品型合同，合同标的物是某些标准产品或材料；服务型合同，合同标的物是提供某种专业技术服务。这里就不多举例。
合同交付内容分类
- 项目型合同
- 产品合同
- 服务合同
-…
财务的视角上看在财务上无论是权责发生制，还是收付实现制，合同是财务核算成本和收入的法定的载体。注意，闲人这里用了法定二字，足以可见，合同的重要程度。
老外VSM的流程设计方法论，其本质就是起点为合同为载体的增值过程分析。
国内实施项目上常用的流程串联图，是基于这一方法论下另一种视角，两者起点和都是一样的，合同和交付。
二、项目制企业的合同、项目和WBS的大坑
项目制企业，闲人在之前的文章有多次提到，业务的开展以项目为单位。在项目制企业中，业务和财务从表面上看，是“一致”的，对于用户经常挂在嘴边的项目，理所当然的认为这里面是既定成宿的一种企业管理沉淀。以下说法可能是你在业务调研和蓝图设计上经常遇到：
销售部门：我们的合同就是项目，
计划部门：我们按项目做计划，
采购部门：我们大部分材料按项目采购
生产部门：我们的生产执行按项目计划进行生产
财务部门：我们按项目核算，按项目分析成本和收入
让顾问以为这就是项目制企业的特点，在不同部门之间在业务认识上是高度一致。ERP流程设计，就理想的状态就是部门认识高度统一、管理对象一致——此时的你，可能会沉浸在对项目乐观想象中，一定会是个轻松愉快的项目。这里闲人要泼你一盘冰水，先冷一冷，蓝图设计，没有冲突，就必然是在埋雷。这些雷迟早会爆炸。
我们先来看看几个典型的表现：
-收集期初数据，SD销售订单行WBS不全
- PS的收入层WBS没有全部对应SD销售订单行
- 财务报表上出现一个合同对多个项目定义
- 财务报表上出现多个合同对应一个项目定义
- …
这些问题如果出现在上线后，经历过的老顾问，相信是有深刻体会的——拆项目，合项目，拆销售订单，合销售订单，删改PR，PO，生产订单，库存转WBS、拆财务帐，合财务帐…
然后紧急发布一个拆合同拆项目流程，比如这个：
1 发起拆单工作流程通知，需要通知到财务、销售、采购、生产、物流、仓库。注意：发生财务账的项目建议不要拆，涉及历史账务调整，经财务同意方可进行
2 拆单业务执行
2.1 BPM生成新的合同号、工程任务单
2.2 执行ZPSR…接收项目进度计划单
2.3 执行ZPSR…生成新的项目、WBS、网络、里程碑
2.4 执行ZPSR…回传项目结构给BPM
2.5 新旧WBS对照表
2.6 销售订单调整到新WBS
2.7 批量删除采购申请、采购订单
2.8 BPM删除老采购申请和采购订单
2.9 SRM系统删除老PR和PO
2.10 库存转移到新WBS
2.11 批量删除生产订单
2.12 冲销报工
2.13 冲销收入确认、费用报销，调账到新的WBS（已确认收入的不能拆）
2.14 被拆的WBS、网络、物料删除
2.15 BPM推送新WBS上BOM、报工
2.16 执行ZPSR…创建BOM,执行ZPSR…挂接并转储BOM
2.17 跑MRP生成新的采购申请，执行ZPSR…推回BPM
2.18 执行ZPSR…报工
2.19 删除ZTPS…，ZTPS…的老PR，PO推送记录
以上这些都是极为惨痛的教训。
三、合同和项目WBS结构设计
闲人的答案是：
合同和项目区别和联系
合同：对外经营载体，实现收入
项目：对内管理载体，归集成本
合同营收通过项目实现财务核算及合同订单全过程资源管理。
有了本质特点的揭示，我们就有了很明确的切入点，从期末期末财务收入和成本匹配角度一击命中要害。
3.1 核算颗粒度的统一
3.1.2 颗粒度较细的设计方案
这种设计方案，是比较常规的设计思路，当合同标的清单较少，且财务核算上要求对每个合同项做收入成本分析时。可以合同订单的行和WBS一一对应。
比较典型的专业分包合同，合同工作项较少。如下：劳务（税率6%），材料，措施费
此时，
项目定义和合同：一对一关系
项目WBS和合同：多对一关系
项目WBS和合同订单：一对一关系。
这样的关系是比较完美的对应，营销部门、项目管理部门、财务部门之间不会存在信息不对称。但是带来的问题是，核算颗粒度过细，数据量曾几何级增长，对信息系统带来的负荷会很高。
3.1.2 粗颗粒度的设计方案
如上，合同订单的行都指向了同一个项目WBS，也就意味着，财务收入确认的颗粒度到一个合同，不明细到合同标的。
项目定义和合同：一对一关系
项目WBS和合同：一对多关系
项目WBS和合同订单行：一对多关系。
这样的关系，营销部门、项目管理部门、财务部门之间会存在一定的信息不对称，比如营销就不能按单个合同标的实现全过程跟踪，财务核算颗粒度相对较粗。优势是，可以有效的减少数据量，提高后勤部门执行效率。
应该说，以上2种情况，对于PS，SD，财务来说，都是在一个公司代码框架解决，只要蓝图方案的贯彻到位，数据收集的策略紧扣蓝图，风险可控。但是魔鬼往往藏在细节之中…
3.1.3 跨组织协同的合同与项目
很多大集团化公司，为了整合资源，往往玩的更复杂。比如集团下各个子公司，都有权力对外承接合同，可利用其他兄弟单位的资源。如下：某个集团公司，承接了某天然气加气站工程项目合同后，把合同中某几个专业分包给兄弟单位做。围绕项目合同，各个单位各自独立核算
这种就是非常典型常见的集团总包分包模式。
这种在设计项目和WBS时就要特别小心。闲人见过很多翻车的案例，包括6年自己负责的项目，也翻车过，是极为惨痛的教训。
这种通常有2种思路：
第一种：搭建总包公司的项目
这种结构就是典型的EPC结构。总包公司向兄弟单位采购服务、商品或其他，利用公司间交易完成物流和账务流转。
在项目定义的视角，总览总包的项目执行情况。
单个WBS视角，跟踪分包单位的执行情况。
闲人比较推崇这个模式，并且在第一篇中关于Q库存跨公司流转已有提及。目前来看，在技术上还存在一些问题，在最后一步，开票环节有报错，可以通过增强解决，但闲人还待于SAP官方给予解决方案。这样就完美了，可以说这是EPC行业的疫苗级解决方案
第二种：搭建分包公司的项目
这种对应方法，是目前来说用的比较多，比较稳，不会翻车。这里就不用多阐述了，总结就是，
- 总包分包各干各的
- 通过增强字段将总包和分包的项目WBS汇总到一起
- 财务需要用开发手段对公司间账务处理
- WBS的对应会成为部门间信息不对称的风险点
3.2 业务管理单元的统一
有了财务上合同和项目、WBS统一基础上，谈业务上的管理统一才有意义。一上SAP，财务部门地位提高，真不是说说的。
在项目实践中，业务部门在分解业务管理单元，最大只能到财务的级别，闲人称之为业务必须向财务兼容。再直白一点，业务管理的单元只能小于等于财务辅助核算。
分享一个经验，在集成调研阶段，把各个部门使用的主要报表查询维度穷举罗列。如果能在这其中，整理出统一查询查询条件的思路，对客户、对乙方都是双赢。
四、期初上线合同、项目范围
蓝图完成之后，应该即可着手规划把合同和项目的收集范围。
经常会出现的问题环节是，漏数据，闲人最近干的擦屁股活，很大程度是在补期初数据。分享一个经验，把财务部门、营销部门抓到一起，把帐对对清楚，然后给个警告，过了这个村，就没有这个店，只要项（xiao）目（jin ku）财务账，自己帐上有余额的，都梳理出来。
最后的数据，必须是要签字的。。。。。然后，在某些企业，签字画押也形同放屁。。。。。。不过，签字留底总是好习惯，保护自己，更重要也是对客户的负责。
PS：祝愿各位PS同仁的项目能顺利交付。闲人还要在当下的项目继续加班擦屁股。。。。。。。。
