如何编制《APS项目范围说明书》 （一）
每一个参与过项目管理或者学习过项目管理的人都知道《项目范围说明书》是一份多么重要的文件，APS项目当然也不例外。《项目范围说明书》教条主义一点的观点是在APS实施项目开始时编制成文的。事实上它有一个逐渐变化演绎的，且在项目前期立项阶段就需要了。业主方在编制预算时、发放招标文件时、签署实施合同时、项目正式启动到项目验收的所有过程都需要《项目范围说明书》的支撑和指引。
现实的情况却非常不理想，由于APS项目案例不多，可以借鉴的文档更少，同时项目业主方一般都是首次接触APS实施项目，而卖方又基于意愿和/或能力原因，也不会积极编制好的项目范围说明书，再加上双方利益博弈的考量，因此很少的项目能够有一份良好的《项目范围说明书》。糟糕的情况就发生了：
1.业主方编制预算时，项目负责人就头晕了，到底预算是多少？问了几个供应商，好像差别很大。向上申请预算数额大了，担心领导不批准；申请预算数额小了，到时候补充预算，麻烦更大，弄不巧项目也做不下去。
2.业主方招标时，《项目范围说明书》模糊不清，埋下了无穷后患。胆大的供应商什么都答应，反正后面再想办法。谨慎的供应商一大堆澄清要求，也不敢对模糊的要求随便答应，考虑太多，结果报价就高了。有位实施商的老板告诉我，“给客户报价，就好比是赌玉石，项目没做完都不知道人天估多了还是估少了”。
3.招完标，签合同了，问题来了，双方对项目工作内容争议很大，很难达成一致，或者带病进入下一环节。
4.正式实施时，整个项目存在严重的争议、博弈。这样的项目，要么强势的买方把卖方压得死死地,要么狡猾的卖方把买方坑得死死地。实施APS的初衷早被扔得远远地。最后不仅双方伤痕累累，整个行业也是谈虎色变，严重制约了APS的普及推广。
那么APS项目到底该怎么编写《项目范围说明书》呢？先让我们去找找书本的指引，查查PMP手册得到的是“详细的项目范围说明书应包含产品的范围描述、验收标准、可交付成果、项目的主要责任、制约因素、假设条件。”
首先是“产品的范围描述”，对于APS来说就是项目的实施范围，它应该从几个维度来描述：
组织范围：详细描述业主方的哪些工厂、哪些车间、哪些班组，包括什么不包括什么，写清楚就可以了；
涉及的产品范围：业主方可能有很多产品系列，是全覆盖还是部分覆盖，需要在此说明；
计划业务范围：一般来说，APS可以支持的计划业务主要分为3大块，第一块是支持工厂进行远期供需平衡与资源规划（S&OP）、支持各周期的主生产计划编制、支持交期答复（ATP/CTP）、多工厂任务分配等等，一般我们称它为AP（高级计划）。第二块是支持计划部门编制详细的短期的加工计划（常见的是展望3天到一周的日计划），组织颗粒度细化到工序、机台，时间颗粒度细化到分钟级，一般我们称它为AS（高级调度），这一块是APS最难的部分，可能牵涉到非常复杂的约束和优化逻辑。第三块是支持计划部门编制物料计划（MRP），和/或者进行物料齐套分析、欠料分析、替代物料使用方案模拟、物料制约排产等，如果业主方已经在ERP中实现了此类功能，往往就不选用这些业务了。
工序范围：当我们选择了AS时，需要进一步详细描述工序范围，把前面所有产品系列的工序描述出来，工序的颗粒度起先可以粗一点。如果业主方很清楚自己的生产计划逻辑时，可以把工序分分类，分成ABC三类。A类：APS项目需要详细研究其约束和优化逻辑；B类：不需要展开仔细研究，但是需要呈现排产结果（开工时间、完工时间），该结果往往是基于前后道的工序简单推理得出；C类工序：该工序物理上是存在的，但是不需要单独进行计划管理，因此可以合并到临近的工序管理。
IT系统集成范围：根据上面APS项目业务范围，能够大致推理出需要哪些基础数据和业务数据，再根据这些数据存在于哪些现有的IT系统例如ERP、MES、WMS、CAPP、PLM等，确定数据接口涉及的范围。
写清楚了上面这些内容，我们就称它为《项目范围说明书0.1》，整个项目的工作量基本就清晰了。下面是一个案例示范。
用来做预算和初步报价时，需要加上买卖双方的分工职责，写清楚后得到《项目范围说明书0.2》，就可以。
双方分工的职责，通常是这样的：
业主方负责: 数据收集准备；APS建模后的用户接受测试；操作手册编写；项目管理部分工作；组织上线、验收；已有IT系统侧的接口（输入输出）；项目关键节点的评审；接受各种调研、培训；参与各种讨论、评审等。
实施顾问职责通常包括项目管理部分工作；需求调研、总结提炼、送审；方案讨论、编制、送审；建模和APS软件及接口开发；单元测试、组织用户接受测试、组织上线、组织培训等等
下一步，业主方需要进行招标和签署合同了，我们需要持续更新升版《项目范围说明书0.2》，整个内容很多，限于篇幅，我们在后面的文章再来展开，敬请期待！