相信很多同事都会存在这样的困惑，花了很多精力写了几万字的业务解决方案，好像客户并不怎么看。而且后面客户系统用的怎么样貌似跟之前的业务解决方案也没太大关系。谈起验收来，客户也总觉得前面方案没写清楚，没解决好问题，又提出新的问题及要求。为什么会出现这样的情况呢？根源还在于业务解决方案的针对性、落地性不足，没有抓住客户关心的内容，没真正帮客户解决问题。
业务解决方案顾名思义，是需要帮助客户解决业务问题的。不光只是说明存在什么问题，更重要的是要讲清楚如何解决，能够兑现价值的。让客户拿到方案之后可以马上用起来，而不是一叠签署完就放在一边的厚厚文档。
现有方案的问题：
1. 客户问题识别不清晰：业务调研不充分，急急忙忙进入方案编制环节。对于客户问题未能有效识别，未抓住客户痛点，只能套用通用问题。
2. 实施目标大而全：由于问题识别不清晰，缺乏针对性，问题解决的目标建议自然也就容易陷入大而全的描述，而且为了显得方案的“高大上”，言必谈“建体系”。范围框定太大，难以衡量兑现，给自己挖坑。
3. 方案落地与实际业务结合不足：方案落地更多从系统功能角度出发，讲的大多都是要用什么系统功能，方案当中的流程说明大多也只到部门级。功能应用与客户实际业务场景如何结合，保障功能应用好对于业务管理上的前提条件要求都没有涉及。客户拿到方案之后除了知道要用什么功能外，基本跟赛普的咨询成果一样，方案建议是对的，但不知道怎么落地。随着后续上线的过程，业务场景问题逐渐暴露，客户提出新的要求。
4. 缺乏清晰的数据输出成果：ERP系统最重要价值的就是高质量的数据输出，数据是ERP系统的灵魂。通过数据反映目前业务运作的情况及问题，支持高层的决策。只有输入没有输出的系统，相信没有人愿意使用。如果客户在方案当中看不到清晰的系统输出成果，对于方案的重视程度肯定会打上折扣，同时在后续上线过程也很容易产生我们认为的“需求变更”。
5. 缺乏基于输出成果的输入规范要求：有约定明确的数据输出成果，但如果缺乏应用的数据来源输入规范要求，保障不了输出数据的质量，产出数据失真问题的话。那么系统的应用不仅给客户的业务运作带来不了任何价值，相反还会加重业务部门的负担。变成了“数据输入是垃圾，输出的还是垃圾”的失败项目。
以上的种种问题很容易导致现有大部分方案只是作为付款凭证的标的物，而不能真正成为指引客户问题解决的落地性文件。本着客户方案真正“可用”的定位，现有业务解决方案可以融合部分上线规划方案内容进行内容重构。可以分为以下三部分内容：
-
- 业务现状问题分析&实施目标建议（方案整体说明）
- 基于目标实现的业务管理规则（业务流程指引+业务审批权责表+数据质量保障规范，可全部以方案附件形式体现）
- 基于目标实现的IT落地支撑（系统标准功能+初始化参数配置+开发需求实现方案，可全部以方案附件形式体现）
目前我们是将几十甚至上百页的方案给到客户签字确认，基本上没有几个客户会认真把这又厚又长的方案给看完，草草确认之后也不便于使用，没法指导后续的上线，很难解决客户问题。不管是作为方案确认，还是作为付款凭证的签字文档，其实客户重点要看的就是他想要解决的问题你有没有识别到、识别到了打算如何帮他解决。只要我们问题识别的足够清晰，解决问题的手段规划的足够清楚，完全可以将业务现状问题分析&实施目标建议作为方案的整体说明给到客户签字确认即可。其它所有的内容都是围绕着问题具体解决的方案附件，尤其是基于目标实现的业务管理规则部分，方案的落地难就难再这部分，是要真正花时间去分步出具、讨论、确认、发布、宣讲传递的，而且在前面蓝图阶段把这些内容真正理顺，可以大幅度提升后续上线环节工作效率，避免因方案不清晰导致的来回沟通、纠缠。
方案结构重新调整之后那么每部分内容编制需要注意哪些点？接下来我们可以逐一进行分析：
1. 业务现状问题分析&实施目标建议：
要保障这部分内容的质量，重点不在于如何写，关键在于前期工作是否做到位，保障了质量。来看看出具前应该有的工作步骤：1客户业务资料收集解读-2管理问题假设（形成针对性的调研大纲）-3高层访谈-4业务部门访谈-5业务调研总结分析。目前很多同事往往只重点关注了3和4具体访谈的节点，对于一头一尾的资料收集解读、问题假设、调研总结都是快速带过甚至就压根没做，就直接进入方案编制环节了。这种状态下，试问方案的质量能好吗？是不是很多同事在方案编制时都会有觉得前面的调研没了解清楚，方案不好写的感觉？目前很多客户的制度都写的很好，也有咨询公司梳理的成果，但问题在于业务实际执行跟制度上写的完全是两回事。比如很多客户关于签证变更的制度要求上写的都是先申报审批后施工，也要求一单一算，但现场的实际情况往往是相反的。如果我们在前期能够对于客户资料进行详细解读，做好问题假设，在访谈时不是基于现状去问，而是基于假设问题求证、基于制度实际执行情况去了解的话，不仅可以帮助我们快速定位问题，而且就问题的解决方案思考上也能够了解到更多客户制度落地难点的“雷区”，有助于提前排雷。
业务调研总结，对于业务调研工作的整体回顾，项目团队共同头脑风暴，梳理《管理决策树》、《项目成功标尺》，可以以思维导图、PPT的形式进行讨论、梳理，直接形成方案汇报的PPT框架。先基于此内容与客户达成共识，再展开各方案附件的编制，避免直接出具方案后来回修订调整的工作量。但在《管理决策树》、《项目成功标尺》的梳理上，第一需要注意具体问题的聚焦，避免大而全的体系、框架描述；第二需要给出完整且能落地的问题解决方法步骤，以变更为例，想要管好，并不是简单的梳理出变更控制流程，制度里要求及时录入，系统中录入数据而已。需要我们从解决问题的视角思考的更加深入，是哪些因素导致了一线就是不按照流程制度来？我们后面的方案中如何规避这些因素，保障变更业务的规范管理。真正帮客户做到及时录入、先审批后施工、一单一算、一月一清？开放给供应商去录入变更、变更审批过程信息透明、从进度款支付上进行牵引、工程指令单的系统打印、紧急变更的范围界定、与非紧急变更的审批流程效率区分等等，这些才是能够保障解决问题的方法、手段，帮助客户做出改变，看到实实在在的价值！
2. 基于目标实现的业务管理规则：
-
- 业务流程指引:
很多公司都有业务流程，为什么落不下去或者落的过程中会变形？多数的原因一方面是之前的流程梳理只到了部门级，没有到岗位级，对于实际业务的执行缺乏足够的指引；另一方面是制定流程的人（大多为咨询公司或内部运营、企管部门），对于一线业务运作的实际情况了解不足，流程制定偏理想化。
业务流程指引可以考虑让客户各业务部门的业务骨干来负责编写（细化到岗位级，与实际情况相结合）、明源团队辅导修正（重点关注跨部门协同、现状优化、与系统结合落地部分，对于系统关键数据录入要求可融入流程指引当中）、客户高层审批发布的方式来进行优化。当然编制的过程也需要结合实际情况，聚焦到与实施目标解决问题相关的内容上。比如客户的项目总工期不够，压根就不会做内部模拟验房，那么在梳理客服流程的时候，就没必要去梳理这个流程。
业务骨干对于各自负责的业务场景问题最熟悉，梳理的内容易于落地；同时自身参与了梳理编制过程，也是自身的成果，后续系统结合流程指引上线，业务部门的接受度更高，抵触心理会下降；而且这批业务骨干通过流程指引的梳理，对于内部跨专业部门协作内容更加清晰，有助于成长为企业内部复合型人才，有助于晋升职业发展通道更宽广。这批人员过程经营的好，变成我们的铁杆粉丝，会是未来我们口碑传承的星星之火。
-
- 业务审批权责表: 以往我们在梳理这部分内容的时候，更多只关注审批流程明确，很容易忽略了审批表单的确认，导致后续出现反复调整的情况。而且在后续上线使用的过程中，经常会出现由于一线人员发起审批时，表单填写随意、无对应审批附件，导致应用效果不理想的情况。虽然后面这点问题是客户的原因，但如果我们在前期梳理时不仅仅只是明确业务审批流程权责，还能够对于审批表单格式、表单填写规范、审批附件要求一并梳理确认的话，对于客户后续的应用质量及满意度提升有很好的促进作用。
- 数据质量保障规范:
1）系统输出报表说明（明确格式、使用场景、字段口径）
2）报表责任矩阵（各字段口径数据来源的维护人、审核人、报表使用人）
3）历史数据处理方式（录入还是导入、谁收集整理、谁负责确认、处理计划）
4）上线后数据巡检标准，可结合巡检报表
5）数据录入不及时、不准确的奖惩要求
6）需RTS推送报表范围
3. 基于目标实现的IT落地支撑：这部分是我们顾问最拿手的内容，这里就不做过多阐述。注意好两点即可：
-
- 初始化参数配置：系统配置参数请提前与客户沟通明确，尤其像是否启用底价管理、成本预警强控指标这些影响非常大的参数，本身就代表着业务管控要求、权责界定。还有各种编码规则，提前确认，避免后续反复引发的数据调整。
- 开发需求实现方案：所有的需求管理一定要形成清单化，基于需求价值（应用层级、应用频率）及实现代价去综合判断的，给出处理建议。后续的交付更新、验证确认也以清单的形式与客户交互。不用刻意回避、遗漏客户需求，前面不提前谈清楚欠的债，后面到了上线之后是要还的。
每部分的内容都讲完了，可能会有同事问，这么多内容要写完、写好不是要花很多时间，那么我的项目周期会被拉的很长啊！的确，以上这些内容如果都要写到位，确实要花不少的精力与时间，而且也很考验顾问的业务能力。可是我们可以想一想，以前的模式就一定能够节省时间吗，交付效率就高吗？几万字厚厚的方案光写出来就要花1-2周的时间，再跟客户来回几轮沟通修订加上前面调研、后面汇报确认，整个蓝图阶段的时间也至少需要一个半月至两个月时间。加上因为方案质量影响上线之后问题逐渐暴露、应用效果不佳，客户提出新目标要求、优化需求来回沟通博弈，项目越做越难。项目难验收，整个项目周期去到半年以上是必然的。前面不见得能快，后面难收尾周期又拉长，关键还没怎么解决好客户问题，客户满意度不高。那么我们为什么不尝试去做出改变呢？