用友Co-UFIDA实施方法论 V5.2
问、高级顾问，否则会失去信任，所以顾问务必要在提供模板的基础上进行再加工；
b) 售前已调研清楚的需求不要重复调研，可以和客户作一个最终确认；
c) 无论进行什么调研都要求顾问在整个调研活动中占据主动地位，能够控制整个活动的进展，注意客户的反应，确保得到我们想要知道的东西。
d) ERP项目的调研和调研提纲都应该有一定的层次和连贯性，按详细业务流程的顺序进行梳理和调研（如所有的库存业务类型的流程、每个流程点的单据数据和流向、操作岗位等），调研时不要仅限于合同中的产品模块范围（例如应收应付的需求和方案可能和销售和采购业务的管理需求有关），也不要按模块的顺序进行调研，讨论的议题也不要有大的跳跃，要从粗到细，逐步分解和连贯；
e) 二是在尽可能满足客户需求的前提下要尽量结合标准产品的功能在调研过程进行引导，但调研时不能和客户讨论产品功能，只讨论业务需求，产品功能只是在脑海中进行对比，这样，当调研结束时，基于对产品的理解，脑子里就基本上有了解决方案。产品中无法实现的不合理需求尽量通过变通的方式解决，按变通的方案进行引导。
f)
顾问在调研过程中要有引导客户的技巧，调研时要把握总体范围，不要偏题和跑题，引导时要从分析业务流程和实际业务的角度去引导，不能从产品不能满足的角度去引导。
g) 被调查对象多种多样，一般可以分为以下几种类型：
? 一问一答型：顾问问一句，回答一句，不问不答。这种人一般不善言辞，或对业务
不是非常清楚。面对这样的被调查对象，顾问应该要比较主动地询问，尽量多提供选择题，启发被调查对象。
? 发牢骚型：一旦讨论起来，他们经常跑题，发牢骚。对企业存在的问题，不是从自
身找原因，往往总是怪其他部门不合作或其他原因。当然，这些发挥有一部分确实是能够帮助顾问发现企业管理的某些问题，但在有限的时间内我们必须抓住重点，完成预定目标。因此，面对这样的被调查对象，顾问应该把握住调研的主线，引导被调查对象在正轨上适度发挥。
? 怀疑型：被调查对象产生怀疑一般有如下两种原因：一种是企业以前投资引进过类
似的项目，然而由于种种原因，最后没有产生效益，他们认为用友也一样，最终是要失败的，于是对实施ERP抱怀疑态度。另一种原因是对系统了解不深，过分强调自己企业的业务非常复杂，认为ERP是很难或不可能解决的。
针对以上情况，我们一般还可采用如下方法：
? 在调研之前，由客户方项目经理召集被调研的部门人员，先组织内部讨论，或
者提供相关的培训，便于提出问题。
? 顾问要事先准备一份详细的调研提纲，作为调研的依据。
? 但要注意，调研时，千万不能就调研提纲逐一提问，应该启发被调查对象，引
导思路。调研时，由客户方项目经理等关键成员和顾问一起参与调研。客户方
P 29 of 89
用友Co-UFIDA实施方法论 V5.2
项目经理可以协助组织和协调。
? 调研中在双方讨论业务流程时，可将业务流程在白板上画出，用相机拍下来再
安排时间整理成文档，顾问及时整理出当天调研的主要内容，然后交客户方项目小组阅读，看顾问理解的是否正确。
? 也可以调研前请被调查的业务部门先写业务现状报告（包括业务流程描述），
也可以让业务部门先描述业务流程现状。要求在业务现状报告中要反映以下问题：①该业务部门的组织结构，岗位设置和职责；②主要业务和业务流程；③列出目前存在的主要问题，以及迫切需要解决的问题。在基于业务现状做调研和讨论，调研的进程会大大加快。
2.4.2.3.1.3 角色与责任分工
? 用友项目经理职责
1) 审核调研计划、调研提纲和问卷； ? 咨询实施顾问职责
1) 制定调研计划；
2) 准备和提交调研提纲、问卷； 3) 提纲和问卷的培训和答疑； ? 客户项目经理职责
1) 积极配合调研并做好协调工作（落实好人员、资料、场地等）； 2) 必要时应该有相应的授权； 3) 调研内容和计划的审核与确认； ? 客户项目组成员职责
1) 准备相应的资料（业务需求、数据、业务单据、报表等）。
2.4.2.3.1.4 交付成果 交付成果 文档名称 文档性质 （内/外） 外 审批 用友项目经理 客户项目经理 外 用友项目经理 《需求调研问卷》 模板工具 《调研计划》 《需求调研计划》 《需求调研计划》 《需求调研问卷》 《XX需求调研问卷》 《需求调研提纲》 《需求调研提纲》
外 用友项目经理 《一般业务调研提纲》、《分产品的调研提纲》、《行业调研提纲》 P 30 of 89
用友Co-UFIDA实施方法论 V5.2
2.4.2.3.1.5 风险提示
? 项目售前阶段销售团队在售前的过程中如有过度的不合理的承诺，实施顾问在与客户进行接
触初期，最主要的工作就是让客户回归理性，当然合理的需求可以另行谈判。
? 需求调研前用友项目经理一定要把好关，选择有丰富经验的顾问参加调研，否则如果需求确
定不准势必会为以后的实施工作带来麻烦。
2.4.2.3.2 PMS2.2当前业务流程&需求调研 2.4.2.3.2.1 任务描述
通过对业务及流程的调研分析，可以获得业务流程设计、管理模型设计等的必要信息，为规范企业业务管理，流程规范化，为下一步的业务流程设计与需求分析、实施方案设计打下基础。
主要工作任务包括：
? 业务需求调研（企业总体调研、高层调研、部门业务调研）； ? 需求调研报告汇报和确认；
? 需求分析和产品匹配分析、目标业务流程设计； ? 需求分析报告汇报与讨论； ? 确认需求分析报告。
2.4.2.3.2.2 工作策略与方法
开展需求调研；需求调研调研完毕后整理的需求分析报告，并设计客户在新的管理平台的新的业务流程，明确业务流程的优化和变更。
主要包括如下详细任务： 1、 详细业务需求和管理需求调研
a) 主要分为企业总体调研和部门业务调研（按职能部门）两大部分，总体调研和总体调研
主要是指企业（集团）整体运营状况的调研和高层管理需求的调研，如主营业务和业务状况、公司未来几年的战略规划、IT建设规划、集团管控需求等内容。
b) 部门业务调研：可以分组走访企业的各个业务部门，参照调研提纲或调研问卷的内容，
进行总体业务调研（即完整的业务运营流程和处理方式）和详细的业务调研（即各业务环节的运作细节、以及各种特殊情况下的业务变化和相应的处理措施等），以及各部门相应的组织结构、人员编制、业务分类、往来单据、管理需求及基础数据、对业务改善建议和需求目标等等。
c) 每个部门调研完毕以后，都应该让该部门相关人员针对调研内容进行确认，看是否存在
误解和遗漏。
d) 需求调研我们是通过顾问与用户的访谈、用户填写调查问卷及流程图等形式来进行。通
过与项目小组或单位业务人员的会谈，顾问应从各种角度获得企业的业务管理思想和业
P 31 of 89
用友Co-UFIDA实施方法论 V5.2
务处理现状。
2、 需求调研报告讨论与确认
全部需求调研结束后，顾问要将需求调研日志进行汇总，从粗到细，从总体到业务进行归纳和整理，形成整体的需求调研报告；
需求调研报告或需求分析报告要详细向客户方项目组进行汇报、讨论和确认（一般项目可在二个文档中二选一进行确认），确认后才能开始编写实施方案。
3、 需求和产品匹配分析、目标业务流程设计
整个调研工作结束以后，顾问应及时整理、编辑调研的结果，并结合产品和客户方项目组一起共同对客户的需求、业务流程、数据规范进行分析和讨论，确定目标业务流程和问题的解决方案，并对客户方的管理（如岗位和职责的调整等）和业务流程改进提出具体的建议。
需求分析报告要分析客户方需求的合理性、每个业务流程的合理性和优化建议、目标流程的定义（流程图）和差异分析、数据规则的变化、管控需求的实现方式和对数据、流程的要求，对系统对组织、制度变革的要求等。需求分析报告中还要明确每个业务流程未来哪些是要在系统内运行，哪些环节是在系统外运行的。
需求分析报告可参见相应行业的文档模板。
4、 需求分析报告的汇报、讨论和确认
需求分析报告初稿完成后，要向双方项目组进行详细的讲解和汇报，并逐项讨论，修改后形成需求分析报告的终稿，确认后作为确定系统解决方案的依据。 项目经理在审核需求报告时应注意以下几点：
a) 对各管理环节和业务流程现状所做的描述是否清楚； b) 对各管理环节和业务流程现状所做的分析是否正确； c) 业务流程和管理改进建议是否合理；
d) 然后再做产品功能匹配，决定哪些需求（特殊业务处理）需通过客户化开发解决； 1）在需求分析报告中的产品功能匹配部分，需将用户业务和管理需求分解为三部分：即标准产品功能满足的需求和必须进行客户化开发才能满足的需求、不在系统中解决的需求（手工或变通的方案）。
2）在需求调研和分析期间，一定要用户方项目组成员的全程参与。因为经过对关键用户标准产品的培训，用户方项目组成员已经对软件产品的总体思想和功能要素有了一定程度的了解，在需求分析时，可以合理规避一些不能实现的需求；同时，经过ERP管理理念的宣讲，可以充分说服用户改变一些习惯性的、不合理的业务管理需求。需求分析报告是由项目组双方成员确定的，最终由双方项目经理在需求分析报告上签字确认。 5、 确认需求分析报告
1) 需求和产品匹配分析完毕后，用友项目经理须向客户提交并讲解最终的需求分析报告，
P 32 of 89
相关推荐：
loading