S1项目-准备阶段

S1，接手的第一个项目。虽说项目具有独特性，每个项目参与进去，都能发现不一样的坑位，但仍觉得S1项目的坑，极具别致性。这也是为什么实施时常常感叹，做项目太有意思了。

项目立项

项目发起，源于Sponsor年初规划，费用控制，包含预算、税票、对公报销、对私报销。报销模块一期聚焦对公，而相关业务中，一大半源于采购。生产物料采购，在ERP，PR、PO、接收、检验、入库，再到AP付款；非生产物料，业务分散，场景众多，流程割裂。申请&采购履行与付款在多个系统中，系统间无信息流转。提交S1项目付款时，就切身感受到了痛点，所有信息都需手工填写，花了40min才完成提交。可以想象，业务月对账发起付款，几十行，小半天就耗在上面了。因此领导的注意力转到非生产物料采购业务，紧接着转到供应商管理关系平台。

回到目项目费控，为什么年初被立项。一是财务信息化建设的需求，一个企业信息化水平的高低，可由财务信息化水平决定。数字化转型的变革之路，也往往始于财务。Sponsor上任，主推变革。变革响应最积极、同时见效最快者，即是财务。费控平台，作为财务集成共享平台的基石，在规划中优先搭建；二是以Sponsor视角，干系人等于高层领导。而高层领导对于IT的直观体验，70%源于审批。把审批做好，关键干系人的满意度就能提升一大截。而审批的痛点，N个系统登录审批，切换不同游览器，账号/密码不一致（SSO已解决）；只能PC端审批，无移动审批；重复审批，需求申请、合同、付款每一环节都要把控；老OA技术落后，界面不友好。基于此，上线BPM系统。通用流程，在BPM。专业流程，由各管理软件承载，同时支持移动审批，集成到IM消息推送中。

输出前期方案汇报，包括问题及痛点分析、项目背景、项目目标、项目范围、实施步骤、整体蓝图方案、业务流程、计划进度、项目概算、收益、资源需求。

POC

理完前置项，回到S1项目。由非生产采购业务，涉及申请、合同、验收、付款，扩展到供应商管理、寻源、招投标、目录商城，进而确定功能范围。POC联系三家，各做了三四次介绍，听下来，感觉差不多，都能做，就看二开的量了。之所以POC听不出区别， 在于双方对于功能清单，都不足够了解。这是甲方常犯的问题，没有真正想清楚，就开启项目。关键功能清单描述的是模块层级上的功能点，大概知道自己要什么。正因为问题是泛泛的，回答自然笼统——能做，基本功能可以满足，但会有少量的项目二开；另一个原因，在于乙方销售没时间、也没必要细扣功能清单。POC场景列的不具体、不全面，演示作用甚微。在这种情况下销售的个人能力，会严重影响对产品的评估。案例对上了、令人信服，保障分到手。将个人与产品，建立了联系。此外，销售与交付往往属于两个团队。销售的业绩，在于签单量。为了KPI，难免会在介绍时夸大其词，为甲方、交付团队挖坑。销售传递的价值、客户认为的价值、产品实际交付的价值、客户接收的价值，永远存在gap，要靠项目的拉扯，来对齐。而对于乙方，如何避免销售为了自身业绩，给交付挖坑，是个长久以来就存在的管理难题。毕竟销售给公司带来的，是实实在在的签单，是收入。而交付又会反对，项目是谈成了，但由于甲方错误的期望，实施困难，为了填坑延长进度，做了成赔本项目，销售也需担责。往往这种争吵，是销售获胜。因此对于乙方项目经理，感叹之余能做的就是努力打怪成长，尽早做到销售，去坑他人。。

让POC真正发挥作用的关键，在于场景的梳理，但确实很难。特别是交叉项众多、涉及多个业务部门的系统，A部门的痛点无法对应B部门的需求，可系统会同时影响到A、B两部门。因此在项目未开始、项目组未成立时，相关业务部门配合梳理场景的参与度极低，提供的功能清单质量无法保证。即使是提出痛点需求的A部门，也不会认真、彻底的列举全场景，一是意愿不足，二是能力不够。这里的能力，是指没有实际操作系统，或要签字蓝图方案的前提下，想出相对完整、准确需求的能力。事实上，这是不可能具备的能力，就像码的代码，让你光靠看、而不编译来找bug，impossible。

既然听完POC，感觉三家差不多，功能模块大同小异，就要评估开发了，能否满足个性化的要求。或者为了达到质量，需要多少的开发量。提供技术验证清单，